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. 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
