Summary: | net-analyzer/flow-tools - PIDFILE is stored in /var/run and init.d script uses PIDFILE.PORT instead | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Reuben Farrelly <reuben-gentoo-bugzilla> |
Component: | [OLD] Server | Assignee: | Gentoo Netmon project <netmon> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 332633 |
Description
Reuben Farrelly
2013-09-04 12:13:23 UTC
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. |