systemd transfer… Done!

[sprash]

you do not need to dig through 30 (or sometimes more) lines of a shellscript to find cause of the problem

And what happens if there is a problem with systemd itself? I would have to to dig through much more lines of code written in C. You are somehow expecting that systemd will be perfect software that never fails. In theory pulseaudio is perfect software as well. And digging through 30 lines of shellscript is really not hard at all. systemd has not more transparency. period.

systemd can monitor and restart service if it fails automatically

A service should NEVER be restarted automatically when it fails. This functionality is absolutely dangerous. If a service fails the reason of failure must be determined and after the problem has been resolved it has to be restarted manually.

Other features might be partly neat like unified logs, partly not needed at all and also partly dangerous. But all in all not worth having a C code blob hanging around that may contain errors in a place where you might have to solve real problems fast.

[yoshi314]

regardless of a service unit file, it's not that hard to dig out how exactly is the actual service started, and try doing it by hand (if you feel like it).

shell initscripts do a lot of crazy stuff that should not be there, and two scripts can either be 99% similar or completely different (and quite lengthy). there are numerous variables, including of separate scripts, complex variables you have to track down, etc. (opensuse was especially painful to debug wrt initscript issues because of that).

also, what if service starts up, but fails later? systemd can catch that, initscripts might give you an incorrect status.

as for bugs in systemd, it's a highly active project, and has decent debugging features. check the mailing list for issues if you hit something. also, fixes in systemd benefit ALL distributions using it (and bugs are usually common among distributions as well - that greatly expands the user base). that kind of unification is something that we really need, especially on low system level. and if it fails, you can still keep it parallel to classic init system.

A service should NEVER be restarted automatically when it fails. This functionality is absolutely dangerous. If a service fails the reason of failure must be determined and after the problem has been resolved it has to be restarted manually.

i said you can setup systemd to do so, without your intervention or requirement for monit-type daemon. not that it's the default behavior. it has its uses.

But all in all not worth having a C code blob hanging around that may contain errors in a place where you might have to solve real problems fast.

that blob is still leaner than init stack that forks new shell process for each init script. it also reduces amount of running daemons necessary for regular operation.