Next Previous Contents

5. cflowd debugging

There are a number of things to examine when trying to find a problem with cflowdmux or cflowd.

The first is the syslog messages. In general, error messages will indicate a problem (and should always be included in requests for assistance, whether directed at the author or the mailing list).

The second is the socket status. On most UNIX systems, the output of netstat -an will show you open sockets. You should look for open sockets on UDP ports for each unique CFDATAPORT in cflowd.conf. If you do not find an open socket for one of the CFDATAPORT ports, there is a serious problem (and you should report it to the author). If you see a large receive queue value (on those systems that report the queue length) for prolonged periods on any of the CFDATAPORT ports, there is a serious problem (which should be reported to the author). Again using netstat -an, you should look for an open TCP port in the LISTEN state for the TCPCOLLECTPORT specified in the OPTIONS stanza of cflowd.conf. The lack of a socket in this state will prevent cfdcollect from working, and is a serious problem which should be reported to the author.

A third source of information is the status of the shared memory segment and the semaphore set. These can be seen with ipcs -a on most UNIX systems. You should see a shared memory segment owned by the user running cflowdmux, and at least 2 processes should be attached (cflowdmux and cflowd). The shared memory segment should be approximately 2 megabytes in length. You should also see a semaphore set owned by the user running cflowdmux. The size of the semaphore set should be 2.

A final handy source of information is the output of lsof(8) if you have it on your system. In particular, the output of lsof -p PID where PID is the process ID of cflowdmux or cflowd.

Next Previous Contents