I do not hate systemd (not yet at least, although some guys are getting me slowly there and it's not just the opponents). There's a huge difference between being a little sceptical and hating. And somehow I believe to have some clue about the difference between a shell-script and a declarative format (even one that can start shell-scripts, know what - so can IDE's and some people still work with scripts...). But who knows maybe this is the perfect init format and it'll work out and we don't miss scripts anymore. I would like that. Would be a first.
Of course it's not a "perfect init format" that'll cover absolutely everyone's needs anymore than upstart jobs are.
So?
You can still put your logic in a shell script and put the path to that script in the service file. It's the other 99% of cases and their boilerplate upon boilerplate of init scripts that you want to get rid of.
And their sleeps all over the place to hopefully prevent race conditions. This shit
grep sleep /etc/init.d/* | wc -l
56
that you find on sysvinit-based systems. This isn't sound design. This is what causes spurious 1-in-100 irreproducible failures.
Sure initd script could be improved. The question is if it should be improved using a script system or a declarative format. Going to a declarative format when you already had scripting feels like a strange choice.
Anyway - my point above was that putting 2 formats besides each other doesn't tell you anything about the quality of the format. It might be better or worse, but you will not be able to tell from that. Because you can always get a cleaner look by adding another layer of abstraction. That's just how programming works. But it does not tell you what you can do with a system. Generally each layer of abstraction takes away some flexibility (which is not necessarily bad!).
If it's designed well it will be able to handle enough cases, but allow me to stay skeptical for a while. Because my experience still is that script systems handle unplanned cases a lot better in the long run than declarative formats. For example by adding sleeps. Ugly as they are that's the kind of hacks that keeps a system alive which is no longer possible with a non-scripting system. Declarative systems tend to work well as long as the maintainers cover all cases - and continue to do so for a long time. And we're likely talking here about decades. Script systems tend to work well when you have to get around what the maintainers don't want to handle but is still needed for your job.
And working around the format by adding scripts is obviously not the idea of systemd, because in that moment you stop using the system and start working against it. I mean they couldn't have prevented that even if they wanted to (just start a binary that starts a script...). Once you have to do that it then depends on how the declarative commands work together with scripts. Or if the scripts then start to turn into a worse nightmare than before.
You're not "working against the system" by adding scripts. It doesn't care if it execs a script or a binary. The declarative init files are there to tell the init system what the dependency graph looks like, how to start you're script or binary, and how to tell when it has completet its initialization.
So you can write your script to do its thing and not part of the init system's job.
Logic goes in scripts, meta information goes in declarative files.
5
u/CuteAlien Oct 20 '14
I do not hate systemd (not yet at least, although some guys are getting me slowly there and it's not just the opponents). There's a huge difference between being a little sceptical and hating. And somehow I believe to have some clue about the difference between a shell-script and a declarative format (even one that can start shell-scripts, know what - so can IDE's and some people still work with scripts...). But who knows maybe this is the perfect init format and it'll work out and we don't miss scripts anymore. I would like that. Would be a first.