systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 21:32 UTC (Tue) by vonbrand (subscriber, #4458)
In reply to: systemd & the tightly couple core band vs a world of many inits by oldtomas
Parent article: Shuttleworth: Quality has a new name

To me, the baroque SysVinit scripts are some of the more opaque code I've ever seen. This stuff is definitively not easily hackable at all (yes, I had to tweak some of those scripts and even wrote a few very simple ones from scratch). Besides, the whole idea is very fundamentally broken: There can't be a "reasonable order for starting/shutting down services," the same way as just adding some "precedence" doesn't help a bit at figuring out the prerequisites, even less making sure they are all running OK before starting something. It was enough for SysVr4 (i.e., server-ish machines which were started in some almost unchanging configuration once a month or so), but it definitely doesn't cut it for today's ever-changing desktops.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 21:45 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

I have no trouble with the idea that desktops/laptops/tablets want to do things differently then how servers have done it for years.

However, I do have trouble with the idea that if it's a good thing for (some/many) laptops, then servers and embedded devices need to use it as well.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 24, 2012 23:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

My embedded devices use SystemD for socket activation and startup. It works really really great.

And I won't mind systemd's containment functionality on my servers.

For instance, a SIMPLE task like "allow the Java program started by this script to listen on port 80" is not really possible with initscripts. At least my puny brain was not able to cope with all the capability inheritance over UID change crap.

With systemd? It's easy! A few lines in the service file and you're done.

Ditto for filesystem containment and secure /tmp.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 25, 2012 5:33 UTC (Wed) by misc (subscriber, #73730) [Link]

With software such as bind ( where you never can be sure that it got shutdown thanks to the rdnc message passing system to close it ), or apache, where I routinely see restart being blocked by some child that only arcane shell can kill, I would be among the first to celebrate systemd and cgroup controled process on the server.

I faced issue with sympa not starting and blocking on wait because it needed postgresql to be started first. We see issues with some daemons starting faster than the network card ( cause network service say "ok, i am ok", while it is not, Mandriva used to have a service "network-up" just for that ).

The way we set limit on file descriptor or anything is dependent on the initscript, the distribution, and usually hard to automate. With systemd, that's just .ini, in well defined location with the same and guaranteed semantics, something that is much easier to automate and to deploy.

The old approach was fragile and, stuff like "having 3 openvpn" was done by cut and paste of the initscripts, that's not really ideal IMHO. There is lots of duplicated code in all initscripts from distribution, and that's not how I envision long term maintainance. Gentoo init system was a fresh approach on that point, kudos to them, and systemd push that further.

I cannot comment on embedded device, but for a server, I see the values, even if I understand that some people feel the sysv init way to be fine for them.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 22:49 UTC (Sat) by speedster1 (guest, #8143) [Link] (5 responses)

> To me, the baroque SysVinit scripts are some of the more opaque code I've ever seen. This stuff is definitively not easily hackable at all (yes, I had to tweak some of those scripts and even wrote a few very simple ones from scratch).

I'm curious which startup scripts you ran across that were a painful mess. I've dealt with plenty of classic init scripts on RHEL/CentOS, debian, and embedded systems and none of those seemed hard to customize when needed. Plenty of startup scripts for custom services as well. Wondering if our standards for painful shell code are different, or if you were poking in an area that I never had to modify.

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 23:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

How about Postfix or something like Tomcat or Jetty?

And I still can't get why my BIND hangs during shutdown (something to do with RNDC which I just don't have energy to debug).

systemd & the tightly couple core band vs a world of many inits

Posted Apr 28, 2012 23:52 UTC (Sat) by speedster1 (guest, #8143) [Link]

Never dealt with any of those, so maybe my running services are just better behaved and don't require twisted setup scripts... exim, dovecot, lighttpd, dhcp, dnsmasq, apache, mysql, nfs, upnp, vnc, mdadm etc

systemd & the tightly couple core band vs a world of many inits

Posted Apr 29, 2012 1:21 UTC (Sun) by jimparis (guest, #38647) [Link]

> And I still can't get why my BIND hangs during shutdown

If you're running Debian or Ubuntu: http://bugs.debian.org/570852

systemd & the tightly couple core band vs a world of many inits

Posted Apr 29, 2012 10:10 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

I've dealt with plenty of classic init scripts on RHEL/CentOS, debian, and embedded systems and none of those seemed hard to customize when needed.

They are still 90% boiler plate, and distribution-specific boiler plate at that. If systemd did nothing except replacing that boiler plate with small distribution-independent configuration files (which is a minuscule part of what it actually does) it would still be a net win.

A bit of boilerplate is not always a big deal, but systemd respawn is nice

Posted Apr 29, 2012 18:29 UTC (Sun) by speedster1 (guest, #8143) [Link]

If you mean net win on the large scale, for developers of large distros, I'd agree with you. However there are other niches where systemd would not win on that basis.

Boilerplate code is not automatically terrible in all situations. For projects that have lots of churn, it can be a hiding place for bugs unless there are good automated tools to ensure every instance gets updated. If the boilerplate is horribly ugly, it can make your eyes hurt from having to look at it so often.

However the init scripts on my embedded projects don't fit that category, nor RHEL init scripts for a non-embedded project, nor the init scripts on my debian server, nor the init scripts on my gentoo development station. The scripts are normal-looking shell scripts which are all the more easily understood because they follow a common pattern and well-known purpose. For a small number of already well-behaved systems (not servers that must run somewhat ill-behaved services), switching from shell scripts to denser config files may not offer any benefit.

BUT, for my embedded projects, systemd does currently offer one much more compelling feature than replacing some small easily-understood shell scripts with even smaller systemd configs: finer respawn control. Busybox init is very limited in that respect. Ability to start and stop a service (init.d), OR ability to respawn (inittab). No control over respawn timing either. In the one current project where we are able to give systemd a spin, configurable respawn policy is the actual practical advantage over sysv-style init for ; we don't have the sorts of daemons that really call for cgroup features otherwise (e.g. misbehaving child processes that don't get cleaned up properly otherwise).