There are a number of init and config related issues with the flow-tools package as in Portage (flow-tools-0.68.5.1-r2.ebuild). These problems revolve mostly around the handling of the PID file when the daemon starts. Specifically, the default flow-tools configure file (/etc/conf.d/flowcapture) has PIDFILE defined in it, and the value of this is used to start the flow-capture daemon in the init script (/etc/init.d/flowcapture). Neither is actually written, resulting in problems with the status and stopping of the service. The issues with the implementation of this at the moment are: 1. The default is to write the pid to the location /var/run/flowcapture.pid and not just /run/flowcapture.pid. This is minor. 2. Even though PIDFILE is defined in the /etc/conf.d/flowcapture config file as: PIDFILE=/var/run/flowcapture.pid the daemon is unable to actually write it's PID file into the default /var/run or /run anyway, on account of system permissions of this directory of 755(root,root). I would guess that the daemon is attempting to write the PID file as it's unprivileged user (flows) and not root, so it silently fails. Perhaps we can get around this by using 'checkpath --directory /run/flowcapture' to create a flowcapture directory with appropriate ownership in /run when starting? 3. The PIDFILE value is then again supposed to write a new PID in a different format entirely as part of the /etc/init.d/flowcapture start(): --pidfile ${PIDFILE}.${PORT} This file also doesn't end up being written, so the system has no idea what PID the flow-tools daemon is actually running as. It's not clear to me we need to write the PID into run two different formats anyway. The net result of this is that: - The service appears to start successfully and in fact does start - The status of the service according to the init script is then 'crashed', although the service is actually running successfully - Attempting to stop the service manually or shutting down the system results in a message like this: start-stop-daemon: fopen `/run/flowcapture.pid.2055': No such file or directory ...and the only way to kill the service is to killall -TERM it.
I can confirm that adding: checkpath -o flows -d /run/flowcapture to the init script start() after the ebegin statement, seems to fix the problems with status and shutdown. The system then seems to be able to track the flow-capture processes properly, and start and stop them on demand. It seems that the daemon itself is still not writing a pid file but I'm not sure that is a problem, since the init script is able to at least now control the service properly.
(In reply to Reuben Farrelly from comment #0) > The issues with the implementation of this at the moment are: > > 1. The default is to write the pid to the location /var/run/flowcapture.pid > and not just /run/flowcapture.pid. This is minor. No, that's the main issue here. > PIDFILE=/var/run/flowcapture.pid > > the daemon is unable to actually write it's PID file into the default > /var/run or /run anyway, on account of system permissions of this directory > of 755(root,root). I would guess that the daemon is attempting to write the > PID file as it's unprivileged user (flows) and not root, so it silently > fails. Perhaps we can get around this by using 'checkpath --directory > /run/flowcapture' to create a flowcapture directory with appropriate > ownership in /run when starting? Yes. > 3. The PIDFILE value is then again supposed to write a new PID in a > different format entirely as part of the /etc/init.d/flowcapture start(): > > --pidfile ${PIDFILE}.${PORT} This, however confusing, is the expected behaviour. flow-capture appends ".${PORT}" by itself so we call s-s-d like that so that it knows too. I have made some changes (without a revision bump). Please re-emerge and report back.
Ok much better now. The only remaining issues I am running into is with a clean install upon which flowcapture fails to start: 1. In /var/log/syslog we see: Apr 12 21:57:21 lightning flow-capture[11092]: chdir(/var/lib/flows/ft): No such file or directory If I manually create the /var/lib/flows/ft directory it then otherwise starts up and runs, and creates the necessary symlinks from there on: ft-v05.2014-04-12.215925-0700 -> /var/lib/flows/ft/ft-v05.2014-04-12.215925-0700 2. The daemon appears to "succeed" from an initscript perspective even if the above critical error occurs: lightning flows # /etc/init.d/flowcapture start * Starting flow-capture ... [ ok ] lightning flows # We actually end up in a status of this: lightning flows # /etc/init.d/flowcapture status * status: crashed Which requires a zap and start again once the underlying error is fixed. I would expect a failed status, not a success when the service fails to start.
13 Apr 2014; Jeroen Roovers <jer@gentoo.org> flow-tools-0.68.5.1-r2.ebuild: Set keepdir /var/lib/flows/ft (bug #483590). Use prune_libtool_files. Set up user/group in pkg_preinst() too.
