On Tue, 18 Feb 2014 11:46:14 +0800 Mark David Dumlao wrote: > init scripts, in general, are ad-hoc, quirky, and incomplete > implementations of service supervision in bash. They're reliable so > long as the daemon can be relied on to advertise one or all of its > processes in a pid file. Thing is, there are way too many different > possible setups for services for that to be the case. In the average > case watching a PID file works. And since most people use "average > software", most people don't care. That's ok. > > Thing is an init isn't just for "most people". It's for "all people". > It should be reliable for all services. > > 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. > > Was it cherokee's fault? Maybe. But the init script should have told > me that. Or even better, the init script should have done its job and > terminted the processes. See, pid files are just a proxy, they don't > work for all services and all setups. Maybe a process crashes before > it kills its forks. Maybe the server has a restart feature that fails > to write the pid file because the init script created it as root but > the daemon relinquished privileges. Maybe there's a bug somewhere. > Maybe the pid file gets overwritten accidentally. Maybe the pid file > is stale because of a power failure. Point is you don't know until the > service restart which should "just take a sec" costs you maybe an hour > or two in billable time. > > With supervised cgroups that's not a problem. Because all process > forks are grouped together, it doesn't matter if there's a pid file or > not. When its kill time, the daemon and all forks and children go > down. Because they're dynamically created on start, they don't get > stale or point to the wrong process. Sounds to me like the right tool > for the job.
I agree with you. But openrc has cgroups support now for each service started. Thus systemd is not the only solution solving problem you described above. Best regards, Andrew Savchenko
pgpPRQOqUQGFy.pgp
Description: PGP signature
