Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[Andrew Savchenko]

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