Documentation Home
Help! Errors
Help! False Positives
Help! Spam Leakage
Installation Guides
Features
Procedures
SNF Community
Software
Technology
Tools
Direct Support
Glossary
Q&A
SNFServer
Command Line
General
If you run SNFServer at the command line with no parameters you will see the version and build information and then a reminder for how SNFServer should be started:
>SNFServer.exe
SNF Server Version 3.0.2 Build: Jul 28 2009 14:48:00
SNFMulti Engine Version 3.0.11 Build: Aug 21 2009 18:42:5
Use: SNFServer <path-to-config-file>
To correctly start SNFServer it is recommended that you provide the full path to the executable and a full path to the configuration file. So, if you have SNFServer in c:\SNF\ then you might use:
C:\SNF\SNFServer.exe C:\SNF\snf_engine.xml
Or, on a *nix system if you have SNFServer in /var/spool/snfilter then you might use:
/var/spool/snfilter/SNFServer.exe /var/spool/snf_engine.xml
Running In A Window
Normally SNFServer is run as a service / daemon so its output is not seen. However, during your initial testing or when debugging you may run SNFServer from the command line and you will be presented with an animated real-time status display. For example, when I launch the 2-9rc2.25 version on my laptop I see something like this:
>C:\SNF\SNFServer.exe C:\SNF\snf_engine.xml SNF Server Version 3.0.2 Build: Jul 28 2009 14:48:00 SNFMulti Engine Version 3.0.11 Build: Aug 21 2009 18:42:53 Launching with C:\SNF\snf_engine.xml Running. M/min: 0 SP: 0.00% LR:1543682 [0/13 | 0] W:0 C:0 B:0 T:0 S:0
The display starts with version and build information, then a line showing the configuration file being used to control the program. Assuming everything starts up properly you next see the text "Running." If an exception had been thrown on startup that is where the error information would be.
When SNFServer is running you will see a real-time status line updated about once per second. Here is what that line means:
+-------------------------------------------------------------- Messages Per Minute
|
| +--------------------------------------------------- Capture Rate %Spam
| |
| | +--------------------------------------- Latest Rule Match
| | |
v v v
M/min: 0 SP: 0.00% LR:1543682 [0/13 | 0] W:0 C:0 B:0 T:0 S:0
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
Jobs Last Second -------------------+ | | | | | | |
| | | | | | |
Connection Polls Last Second ----------+ | | | | | |
| | | | | |
Queued Jobs Yet To Finish -----------------+ | | | | |
| | | | |
White Override Events Per Minute ---------------+ | | | |
| | | |
Caution Override Events Per Minute -----------------+ | | |
| | |
Black Override Events Per Minute -----------------------+ | |
| |
Truncate Override Events Per Minute ------------------------+ |
|
Virtual Spamtrap Samples Per Minute ----------------------------+
White, Caution, Black, and Truncate Override events are described in the GBUdb - How It Works section.
Virtual Spamtrap Sample events occur at random when the GBUdb detects a known bad source and the pattern matching engine fails to match a spam pattern. This provides a random sampling of "new spam from old bots" to our virtual spamtrap network. This feature can be disabled if desired.
Debug Mode
If you really want to see more details then you can run SNFServer in debug mode, the same way you can run SNFClient in debug mode. That is - by either running it in a path that contains the word debug or by renaming the executable so that it contains the word debug.
The display will update every second or so with the normal update line followed by the thread status information for every thread running in SNFServer. This pushes things off the top of the window very quickly -- but the part you want to see is always visible for a second before it moves on. Below I've captured the first update for you (that is why the load indicator reads [0/0 | 0]).
Here is what it looks like in Debug mode:
>C:\SNF\SNFServer.exe C:\SNF\snf_engine.xml Debug Mode NF Server Version 3.0.2 Build: Jul 28 2009 14:48:00 SNFMulti Engine Version 3.0.11 Build: Aug 21 2009 18:42:53 Launching with C:\SNF\snf_engine.xml Running. M/min: 0 SP: 0.00% LR:1543682 [0/0 | 0] W:0 C:0 B:0 T:0 S:0 Log Manager (2271608), snfLOGmgr, Thread Started, Running, Ok, Second Status Logger (2292404), DiscLogger, Waiting, Running, Ok, Minute Status Logger (2292468), DiscLogger, Waiting, Running, Ok, Hour Status Logger (2292532), DiscLogger, Waiting, Running, Ok, XML Scan Logger (2292596), DiscLogger, Waiting, Running, Ok, Classic Scan Logger (2292660), DiscLogger, Waiting, Running, Ok, NET Manager (2292728), snfNETManager, Sleeping, Running, Ok, GBUdb Manager (2293152), snfGBUdbmgr, Thread Started, Running, Ok, XCI Manager (2293368), snfXCIManager, Checking Config, Running, Ok, C0 (5788528), snfXCITCPChannel, Waiting For Take(), Running, Ok, Reloader (5803248), snf_Reloader, Thread Started, Running, Ok, RulebaseGetter (5803312), Script Caller, Thread Started, Running, Ok, C1 (5838344), snfXCITCPChannel, Waiting For Take(), Running, Ok, C2 (5880440), snfXCITCPChannel, Waiting For Take(), Running, Ok, C3 (5922576), snfXCITCPChannel, Waiting For Take(), Running, Ok,
The thread status information is displayed one thread per line as follows:
+----------------------------------------------------------------------- Thread Name | | +------------------------------------------------------------- Thread ID | | | | +------------------------------------------- Thread Type | | | | | | +----------------------- Thread State | | | | | | | | +-------------- Running Flag | | | | | | | | | | +---------- Broken/Ok Flag | | | | | | | | | | | | +---- Exception | | | | | | | V v v v v v v C3 (5922576), snfXCITCPChannel, Waiting For Take(), Running, Ok,
The threads and types are:
XCI Channel Manager (snfXCIManager)
This is the master thread for the XCI service. It monitors the configuration for the XCI subsystem, listens for XCI requests, and dispatches those requests to the best available Channel Processor.
C0-C3, Channel Processor (snfXCITCPChannel)
These threads handle XCI requests including the TCP traffic from and to the requesting program and all processing required to handle the request. There are four processing channels in the standard SNFServer implementation. This number has proven to be a good performance trade-off for most systems. That is -- a large enough number to take advantage of the available computing power, and a small enough number to leave some room for other processing on the system.
GBUdb Manager (snfGBUdbmgr)
This thread handles administrative, maintenance, and monitoring tasks related to the GBUdb database engine. Most requests to the GBUdb are handled by the thread making the request-- usually a Channel Processor.
Network Manager (snfNETManager)
This thread handles SNF Network Operations including SYNC events.
Log Manager (snfLOGmgr)
This thread manages the system logging oversight functions, statistics gathering, and report formatting.
Second Status Logger (DiscLogger)
This thread handles Per-Second status log file writes.
Minute Status Logger (DiscLogger)
This thread handles Per-Minute status log file writes.
Hour Status Logger (DiscLogger)
This thread handles Per-Hour status log file writes.
XML Scan Logger (DiscLogger)
This thread handles XML format Scan & Activity file writes.
Classic Scan Logger (DiscLogger)
This thread handles Classic format Scan & Activity file writes.
RulebaseGetter (Script Caller)
This thread launches the rulebase getting script via a system() call when triggered and enforces the guard time clock.
Reloader (snf_Reloader)
This thread checks the configuration and rulebase files for changes and reloads the rulebase manager when a change / update is detected.
Please email support@armresearch.com with any questions.