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.