Comment 3VF Re: sysvinit was a dead end


Linux kernel hacker's open rant about systemd


sysvinit was a dead end (Score: 4, Insightful)

by on 2014-08-14 00:53 (#3VA)

I'm not a big fan of systemd, but I disagree with the idea that sysvinit didn't need replacement.

It required a large amount of boilerplate in the service start/stop script, which was different between distros, making it a lot of work to provide a decent start/stop script for your daemon. The hard work of distro maintainers hid this nuisance from most end users though.

Ordering the service startup sequence by manually assigning priorities to them (S80myservice) instead of using dependencies is a terrible hack. It also prevents services from being started in parallel, which is a pity on today's multi-core systems. It's like building your code using a shell script instead of a Makefile.

There is no consistency in how services are started: inittab can respawn, init.d scripts can query the service status (on some distros!), (x)inetd can start services on demand, but all have different configurations.

I have some doubts systemd is the right solution to these problems, but at least there is movement now. In my opinion, the solution would be to improve systemd or replace it with something better, not going back to sysvinit.

Re: sysvinit was a dead end (Score: 2, Insightful)

by on 2014-08-14 16:03 (#3VF)

Pretty much echoes my sentiments regarding SysVinit. It gets the job done with minimal resources, but it's not really appropriate for modern systems where a parallel and dependency driven init process is a major user requirement and resources are no longer an issue - especially on desktop and mobile devices where the user would like as near to instant on as possible. Despite that I find SystemD does what it is supposed to without too much fuss, and is in many ways more capable than sysvinit, I also think it's a bloated mess that was badly designed from the start, and when it comes unstuck fixing it is an absolute nightmare. Don't even get me started on the whole DBus integration/requirement thing; that sounds more like something Microsoft would have cooked up for Windows than the core principles of UNIX, and is one of the main reasons that I'm taking a good look at migrating as many of our Linux servers over to BSD as possible when they are next due for a refresh.

PID1 needs to just do the essentials and be a minimal piece of code that is pretty much as close to "hello world" as you can get to avoid complications and failures, everything else should either be an optional SystemD module or an external program depending on the the user's preference. Want SystemD to handle your logging, fine, tell it to load that module and off you go. Want to run a proper daemon that can listen for remote log entries too, then disable the SystemD module and use RSyslog or whatever you prefer. Some functions of SystemD are already modular, but that needs to go a lot further in my view, and requiring stuff like DBUS integration right there in PID1 is just asking for all sorts of stability problems, but it into a module, then at least there's a chance the system might be able to recover without a kernel panic.


Time Reason Points Voter
2014-08-14 21:13 Insightful +1

Junk Status

Not marked as junk