Except that this feature of systemd doesn'trequire any rewriting of services, at all. They just carry on sending output to stdout, stderr, and/or syslog, as they have always done - and the "cgroups" feature ensures the logs can be distinguished and stored appropriately. Doing the same consistently for SysV init would actually be genuinely harder, because (for example) when services are started manually this is done by running a service-specific shell script - so to ensure each service ends up in the right cgroup, you have to add a lot of Linux-specific stuff to each service's startup file.

I'm not yet 100% sold on whether the log filtering is worth all the extra code implementing it - but saying it's "not a big deal" to add the same feature to sysvinit is not telling the whole story.

Apparently systemd has support for a watchdog function for services, so it could potentially notice this (though the service needs to have support for it).

Not to mention crashes caused by rare, hard-to-reproduce race conditions. These do happen (correct multi-threaded programming is hard), and personally I'd prefer it if the process crash didn't take down my websites with it - though of course I do want the logs to let me know, loud and clear! Sure, if the service crashes repeatedly on restart, it needs to be throttled, but I assume systemd can do that (after all, this is one of the things SysV init has always done, at least for getty processes).

Note: systemd is not part of the Linux kernel.

Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies. What's the issue that prevents that working?

Indeed, the syllogism in funwithBSD's post doesn't follow unless one adds an implicit "[but the other one does]" to the first two sentences.

Right - it's not true dependency checking, but it is a way of encoding the the startup dependencies (which is why it's done, after all).

True again - and this is exactly the point; once you do this, and cause the boot process to stall before the point where you can log in, you're just as broken under any init system :)

Sure, anyone can come up with a timeout script that will (effectively) declare a service "ready" if a certain time limit is reached - but again, that will work equally well with any init system. (And did you have a timeout in place for your accidental "sleep 20000"? It's the sort of thing that's easy to add, but usually only with hindsight ;-). Also I think you want $$ rather than $?.

Everything's trivial until you've actually tried it ;-). You can quite quickly do something approximating it, but doing the useful parts (e.g. "start this service, plus everything it needs" - and, better still, "if I were to ask you to start this service, what else would you need to start?") requires a lot more work. In particular, it needs a concept of knowing which services are currently started, which SysV init lacks.

Actually it does, in a clumsy kind of way: you give the services a priority, and services with a lower priority are started before those with a higher priority. So if you have an early-starting service (eg bringing up filesystems) that blocks for a long time, that will delay later-starting services (eg sshd) just as much. If you're lucky, your system's rc scripts may implement a timeout - otherwise you're just as hosed under SysV init as under smf/systemd...

You didn't mention Solaris, only smf, so you could equally have been talking about, say, an Illumos-based distribution... but thanks for clarifying :)

True.

Alas the same is true in practice for SysVinit. And in fact, systemd has better support for overriding the defaults from the vendor/distro packages - though I've never actually used it, so I don't know how well it works in practice.

In practice it's far from trivial.

I can't see how you can make that guarantee. The problem with ssh not starting up was due to the distro/vendor encoding dependencies badly. That can be done just as well with SysV init as with any other system. Depending on how the local "rc" script (or equivalent) is set up, this can lead to the machine hanging indefinitely for no good reason (I've seen it happen enough times!). Alas no init system can protect you from dumb decisions by distros/vendors :-/

It points you to the location of some shell scripts that you have to read and parse in order to find where your particular flavour of *nix stores its Snn* and Knn* symlinks, then look at those... to me that doesn't seem a lot better than having to look at the manpage to find the damn files, but you are entitled to your preference :-)

How would this have been any different with SysV init? That would have translated into sshd being started later than the filesystem, utmp etc - so you'd have had the same issue. In fact it can end up being worse, because a higher-numbered service can end up being delayed by a lower-numbered one, even if it doesn't have any dependency on it at all...

But /etc/inittab only tells a tiny part of the story; you also need to look in /etc/init.d, /etc/rc*.d etc - so not really all that different to what you'd have to do with systemd (except that at least with SysV init you presumably already know where to look ;-)

No, statements are not the same as lines. Lines have real semantic significance in BBC Basic, in a few different ways: for one, GOSUB-type subroutines can only start at the start of a line (because that's where the line number is), and you also can't terminate an "if" without starting a new line. That (plus the 256-byte limit) makes writing one-liners in the language more of a challenge than in other languages where line breaks genuinely aren't significant.

That's actually not true, strictly speaking... XP is still supported, for those (usually governments and large companies) who are willing to pay Microsoft for it...

Not really that unlikely, especially as fatality rates are often given to the nearest 5%...

The trouble is - the single part that you presented is clearly broken (eg it doesn't work well with the way many mailing lists work), so if it conveys the concept of your whole presentation, people are naturally going to assume that the whole presentation was broken...