"With systemd I find myself quite often with no idea where to even look for information about something not starting"

You could read the (currently) 20-part sysadmin guide.

http://0pointer.de/blog/projects/socket-activated-containers...

/sbin/init and its simple shell scripts never required this much explanation.

I read (most of) it, but there's a big difference between "I know how this works" and "I can debug why things don't work as I expect them to work after reading documentation" with systemd. This gap doesn't exist with sysv style init scripts and I couldn't find much information addressing the issue.

You're confusing existing knowledge you already have with how easy another system is. Obviously if you already know one system, the other system will seem more difficult.

I have had my fair share of daemons not starting due to various problems. E.g. openldap (terribly confusing debug messages). Give me systemd any day over the complexity of a lot of those scripts.

Had not seen your comment before adding mine but I think you're spot on. And having had to fight with openladp last week I can only agree with you. I used to know the "old" standard text file config and the new slap.d config style is confusing.

But I think it's comparable to systemd in that if you manage an LDAP directory day to day, the new system probably makes more sens once you're used to it.

We have to relearn the config and, man, sometimes we can be a lazy whiny bunch when we should try to evaluate systemd more objectively ;-)

As an aside, the survey pleased me as I expected more conservatism from Debian

I didn't mean the openldap config. Sometimes the daemon just plainly does not start. You basically have to resort to using strace to figure out what is wrong with the thing. Systemd redirects stderr and stdout, highly useful IMO.

Openldap gives difficult to debug starting problems in loads of cases. E.g. problem in a certificate, config problem, etc. Then you might want to increase the debugging level. Really not fun to look into some script and figure out what actually eventually is passed to the openldap daemon as arguments.

Well, the systemd suite replaces a lot more than "/sbin/init and its simple shell scripts". It is no surprise that it has more documentation.

True. And I find myself struggling more than I'd like to tame the beast.

That said, putting my devil's advocate hat on, if you and I were to start afresh not knowing shell, we'd struggle too. And truth be told, I'm not objective enough to tell if it's easier to learn shell programming or systemd config for a neophyte.

> I really like the idea behind systemd/upstart (they're quite similar in practice)

They're quite different. Upstart is event-based while systemd is based on automatic dependency resolution and socket activation: http://www.youtube.com/watch?v=TyMLi8QF6sw&t=11m18s

I know they're different in how they are constructed. They're similar in what they do. For the majority of people who ever need to do anything with upstart/systemd it will be: it starts a service and its dependencies; it restarts the service that crashes if configured to do so; service operations can be triggered from outside.

Yes, underneath they have completely different implementation, but it shouldn't really matter apart from OS-level edge cases. If it does matter, it's a sign they failed to provide a simple and usable tool in my opinion.

I have not used systemd in practice but my experiences with upstart in practice are very different from both sysvinit and from what I read about systemd. I actually think systemd seems to be closer to sysvinit than to upstart.

EDIT: It is the reversed dependency logic in upstart which makes it so different from anything else.

They are also different in practice. For example, you can kill services cleanly with systemd, because it keeps track of what processes belong to which service via CGroups.

If you're interested in edge cases, then cgroup support can be included in your upstart configuration too. It's not a simple switch in the configuration, but can be made to work in the same way - I do that for some forking services which sometimes fail to collect children properly. I wouldn't consider this to be a big difference between the systems - each has some features that the other doesn't.

Could be be more concrete what service is failing? Systemd for me always gives really good output on why things aren't working.

I haven't used upstart, but this is exactly how I felt when using systemd on Arch.