On 18/02/2014 11:52, J. Roeleveld wrote: > On Tue, February 18, 2014 10:47, Alan McKinnon wrote: >> On 18/02/2014 05:46, Mark David Dumlao wrote: >>> I used to use cherokee. Fast, light, awesome, and with a web admin. >>> The init script always failed me. /etc/init.d/cherokee stop was not a >>> guaranteed stop to all forked cherokee processes - the parent pid >>> dies, but some forked process or something, usually related to >>> rrdtool, doesn't. Or the parent does exit and erases the pid file but >>> it returns control immediately and its not yet done exiting. Something >>> like that or other. Point is, I've several times had to ps aux|grep >>> ... kill; zap; start - on production servers. >> >> >> Valid point. Other than vixie-cron (damn thing just never seems to die >> properly on any platform so restarts always fail) I don't really run >> into these issues > > Interesting, I have never had issues with restarting vixie-cron using the > supplied init-scripts. > >> What I do run into is daemons that drop privs on start up, like >> tac_plus. Unwary new sysadmins always try start/stop it as root, causing >> an unholy mess. Root the owns the log and pid files, when tac_plus drops >> privs it can't record it's state so continues to service requests but >> fails to log any of them. For an auth daemon, that's a serious issue. > > Shouldn't sysadmins use the init-scripts for that? > If done correctly, permissions should not be an issue.
It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. It's exactly analogous to compile-time vs runtime errors, compilers can't catch the latter. Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. The daemon also tries to log these errors, by writing to a log file it has no write permissions on. There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. > > Restarting services without keeping file ownership into account will > always cause issues. Regardless of the init-system used. > > And tac_plus not checking if it is allowed to write to the log during the > initialization phase should be considered a bug. > > -- > Joost > > > > -- Alan McKinnon alan.mckin...@gmail.com
