Re: Init system deba{te|cle}
On Sat, Nov 2, 2013 at 10:06 PM, Reco <recoverym4n@gmail.com> wrote:
> On Sat, 2 Nov 2013 21:08:29 +0000
> Tom H <tomh0665@gmail.com> wrote:
>
>> Misrepresenting what systemd is and the reasons for its existence
>> doesn't make sense:
>>
>> http://0pointer.de/blog/projects/systemd.html
>>
>> OS X and Solaris switched to launchd and smf respectively in 2005 and,
>> to borrow an expression from Asterix and Obelix, "the sky didn't fall
>> on their heads." Modern nix systems need a more sophisticated
>> "/sbin/init" and associated executables and they need (and have needed
>> for a long time) something more reliable and maintainable than a bunch
>> of dash/bash scripts to bring the system up.
>
> I've never seen (nor intend to) launchd, but I'm familiar with smf.
> And while in Solaris "the sky didn't fall on their heads" indeed, smf
> uses ksh scripts for actual launch, check and re-start services like no
> tomorrow. And Solaris's svc.startd is actually started by /sbin/init.
> Whenever the result is more reliable ('forgetting' to start sshd on a
> failed local non-root filesystem mount is one of 'features' of new
> Solaris), or maintainable (yes, I always wanted to describe service
> dependencies in xml) is subjective, of course.
> And smf doesn't provide 'one true API' for service launch nor requires
> services to be written in a specific way.
smf uses manifests to manage the ksh scripts, which are far more
simple that the pre-smf rc scripts; often just a "case,start/stop/..."
mini-script.
So the entire management and supervision of the scripts is done
through the manifests, which are new to smf. The fact that these
manifests are in xml sucks. This is where Scott and Lennart have
improved on both launchd and smf (by not using xml) and on smf (by
combining the control of the scripts and the scripts themselves with
"exec" or "script,end script" in an upstart config file and with
"ExecStart=..." in a service file.
Furthermore, the fact that Solaris uses "/sbin/init" doesn't mean that
it's using that of sysvinit. On Ubuntu, upstart uses its very own
"/sbin/init".
>> Linux is playing catch-up
>> in this field and I'm glad that upstart and systemd are dragging it
>> out of the dark ages, even if it's kicking and screaming irrationally.
>
> Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if
> using good ol' sysvinit. So, Lennart fixed what wasn't broken in the
> first place.
How can you say that sysvinit isn't broken? Did Scott and Lennart both
think "sysvinit is perfect but I'm nonetheless going to develop
upstart/systemd; my employer won't mind my wasting my time on such a
project my distro in a more constructive way"? Both upstart and
systemd were developed in order to improve on sysvinit.
>From a user perspective: with sysvinit, you can't be sure when you
"stop" a daemon that it actually stops.
>From a developer (and to a certain extent user/admin) perspective: the
following is taken from [1].
<begin>
I think it's painfully obvious if you compare an init script to an upstart
or systemd configuration file for a simple daemon like, say, my lbcd
package.
For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle). Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration. (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)
</end>
[1] http://lists.debian.org/debian-devel/2013/10/msg01099.html
Reply to: