cflowd configuration: cflowd debugging

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