Hacker News Reader

Comment by SwellJoe | Hacker News Reader

"I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit?"

27 lines is horribly optimistic. Complex services like Apache, MySQL, etc. could have initscripts hundreds of lines long, plus the library of support scripts that most distros ship to make the initscripts shorter and more manageable. Most initscripts are like 50%, or more, boilerplate that's the same across all services, but, it's still a pain in the ass to maintain them.

I will not miss initscripts, even if I might have some occasional complaints about systemd.

View on HN

As I pointed out at https://news.ycombinator.com/item?id=14169188 , there's a discussion of MySQL on the systemd-devel mailing list right now. Clearly some people in that discussion are not familiar with MySQL. Clearly some of the people in this discussion are not familiar with MySQL either.

To help combat this ignorance, here are some actual systemd units:

* https://github.com/MariaDB/server/blob/10.1/support-files/ma... -- MariaDB's official systemd service unit, 173 lines long

* https://github.com/mysql/mysql-server/blob/5.7/scripts/syste... -- MySQL's official systemd service unit, 60 lines long

* https://github.com/percona/percona-server/blob/5.7/scripts/s... -- Percona's official systemd service unit, 61 lines long

* https://sources.debian.net/src/apache2/2.4.25-3/debian/apach... -- Debian's third party systemd service unit for Apache2, 15 lines long

So these figures that people are pulling out of thin air are erroneous by anywhere from half the actual length to an order of magnitude too small. And, ironically, the Apache systemd service unit is using a System 5 rc shell script under the covers to do all of the work. The apachectl program is in fact a System 5 rc script from 1997, complete with start/stop/restart/status verbs.

Yeah, legacy code is hard, sometimes, and sometimes complexity can't be hidden entirely.

The initscripts for MySQL/MariaDB are still orders of magnitude larger than these (unusually large) systemd unit files. Managing complexity is hard. SystemD helps. More modern service design, and simpler services, helps (compare/contrast Apache startup vs nginx or caddy, or MySQL vs MongoDB; sure, the newer options do less, but they do "enough" for some use cases).

You really should take the tack of learning about this subject rather than following rubbish numbers pulled out of thin air with more rubbish numbers pulled out of thin air. Here's the System 5 rc script for MariaDB. At 453 lines it is not even one order of magnitude larger than the systemd service unit, let alone orders of magnitude.

* https://github.com/MariaDB/server/blob/10.1/support-files/my...

I recommend actually learning about the reality of MongoDB. For starters, the systemd service units supplied in the likes of Ubuntu and Debian do not set any of the settings recommended for MongoDB by its authors, so here (as in so many cases with systemd service units in the wild, alas) shortness actually equates to not doing things properly.

* http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/mo...

* https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mon...

* https://docs.mongodb.com/manual/reference/ulimit/#linux-dist...

Another example of such is WSO2 Carbon, with a 14-line system service unit from one source that gets things grossly wrong.

* http://jdebp.eu./FGA/systemd-house-of-horror/wso2.html

I recommend actually learning about Caddy, too. Ironically, the subject of its service unit came up here on Hacker News only a day ago. It is 43 lines long, some 6 times the length of the supposed 7-line systemd service unit being bandied about here, and not as far different from those for MySQL and Percona as you imply; and it does not attempt to be "more modern" as you claim, as it entirely lacks the socket unit that would make it more in line with the systemd way of doing things.

* https://news.ycombinator.com/item?id=14167704

The idea that this is "modern service design" is borne of not knowing the subject, too. The sort of design changes recommended by the systemd people are in fact pretty much the same sort of design changes recommended by IBM in 1992 for services managed by the System Resource Controller and recommended by quite a lot of other people since, including Apple and ... well ... me for many years. Whilst this is good service design, it is not "modern", and not in any way unique or original to systemd. To further alleviate the ignorance of MySQL as well as demonstrate how this is far from "modern" and not something that one gets to claim for systemd service units, I point out that people were running mysqld without mysql_safe, in the very way that the systemd people are by all appearances just learning about in their mailing list discussion, under daemontools in 2002. I strongly suspect that that wasn't even the earliest occasion of that.

* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...

Counting empty lines and comments is hardly the way to make your point. The mariadb unit file you linked to is only 34 actual lines, the mysql unit file only 22, percona 23.

And if you're writing your own unit files rather than ones for public consumption, you probably won't include lines like "Documentation=" and some other minor args.

Actually, counting lines, whether empty, comment, or otherwise, very much is the way to make the point. The reality of actual service units that people write is not anything like the picture that was being painted. You erroneously think that the point is that short is good and long is bad, rather than what it actually is, which is learn the subject and don't make facile arguments based upon rubbish numbers plucked from thin air. Actually looking at reality and counting, rather than pulling the number 7 from a hat, is part of that point.

I recommend reading the design of the Mewburn rc system, http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... , and some of the entries in the systemd House of Horror. This whole "It's just writing 7 lines and it's easy!" argument falls apart when one looks at the reality of short service units that are either grossly wrong or turn out to be underpinned by the very things that their lengths are being compared to (which also means that it is still those rc scripts that are being used and maintained by software authors -- from 1997 in the example of apachectl), real world service units that are not short, other systems of long standing that are equally concise, and -- yes -- the reality that people include commentary for maintainability.

One of the amusing things about this argument that is of particular relevance to the Devuan release is that back when Devuan was announced someone put up a "fork Fedora" WWW page criticizing the Devuan people, with a systemd service unit side by side with a van Smoorenburg rc script. It is sad to note that few people observed that the systemd unit described just one service, whereas the van Smoorenburg rc script ran two. Since you are on the subject of commentary, I invite you to observe which of the twain included comments and which did not, as well, and determine what point the "fork Fedora" people were in fact demonstrating. (-:

Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder when these people actually come down from their ivory towers to do some real life work, where the rubber meets the road.

The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle?

systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window.

The systemd people should be made to work building and maintaining a real-life backend environment for a while.

To be fair, mariadb systemd unit is 173 lines of ini-style configuration. Not 173 lines of bash code. There's a massive difference.

Also most of it is commented as examples.

You don't maintain an init script. You write it once. It doesn't do anything but run a program with an argument. There is no need to modify it except once every few years if your system or your application changes significantly in how it is started or stopped.

On Slack, the init scripts range from 6 lines (rc.font) to 445 lines (rc.S). Mean: 105, Median: 64, Mode: 56, 36, 48. BSD probably has even less complicated init scripts.

Your system might have more complicated init scripts, but it doesn't need them to be complicated. I suggest you direct your ire at your distribution, not init. (Most distributions totally misuse init and try to make it do things it was not intended for)

However, few sysv init scripts are the same structure. Each one is written by different people, who do things slightly different ways (and occasionally get things slightly wrong), and on different distros they use different tools. Debugging sysv init scripts is more complex than debugging a systemd unit file.

One example that neither camp does well is 'status'. Systemd is too verbose, but at least always the same standard output. Sysv init is whatever random noise the author decides to put out. Sometimes it's multiline. Sometimes it's no line, but an exit code. Sometimes it has colour. Sometimes it doesn't tell you whether it's running or not, but just outputs the service name. Sometimes you just have to be familiar enough with running the service such that you have what the status lines actually mean already in your head.

> It doesn't do anything but run a program with an argument.

It also needs to find that program again in order to provide status on it, stop it, and if the application has support, reload it. Very few init scripts are fire-and-forget startup scripts.

If you don't like the internal structure, you can change it! If you don't like the output formatting, you can change it! All with a few lines of shell script, immediately, no compiling, no rebooting!

You can't say the same of systemd. It has to be whatever systemd has compiled in. (Which, by default, is terse status, followed possibly by journal data, or just system status if no units are available) Sysctl status also loads a unit at run time, and then may unload it afterward, meaning it is not useful to see if a unit was already loaded. It also uses a UTF colored dot, combined with different lines that can be interpreted different ways. In other words: it is a complex arrangement of information. And for machine output, you need the 'show' command, and more options.

With sysv, you ask it for status and it tells you if it's running, if the script supports status. Clearly a complicated mess.

Your last comments don't make sense. Sysv init scripts don't have to "find" a program any more than any other method of executing a program. And all init scripts I can think of are fire-and-forget, as much as systemd or any other init program is. The only thing they don't do is continue to try the same operation over time or wait around for a dependency, if that's what you meant (which Sysv scripts aren't really supposed to do, but inittab supports it anyway)

I'll do you one better on your first comment: ALL Sysv init scripts are a different "structure" internally. Even in the way they are used! The reason is, they're just scripts. Outside of inittab, there is no real standard for how they work, so each system makes them work however they wish. They can write them so they're all the same, or all different, and make them called the same or different, and give them different features, or no features. This is why some people love Sysv - it is totally flexible. You can make it do anything you want, and all you need to know is csh.

With other apps (not just systemd, but lots of things) complicated custom domain-specific languages are invented to do little things, like change configuration files' permissions, or send a file somewhere. Csh/Bash allows you to do the same, except it's a lingua franca that is compatible with every Unix-like operating system. It's interpreted, it's flexible, it's portable, it's backwards compatible, it's composable, it's extendable.... I mean, this is really an amazing thing that no other language or tool can claim (other than web browsers). Any problem you have with Sysv you can fix it within Sysv, without requiring compiling code, or even rebooting. I know i'm beating a dead horse here, but I just can't see how anyone would want to throw all this amazing power away or see it as limiting.

If you wanted, you could write a systemd clone in bash, and make service/unit files out of bash. I don't know why nobody has done this yet, but probably because it would be self-defeating.

>27 lines is horribly optimistic

Yes of course, I was referring to the skeleton script in wheezy to be fair. ;)

A more normal systemd unit I wrote for one of my own services is actually 15 lines but that's for a Python service, with virtualenv and above all no shell script wrapping.

Reply on news.ycombinator.com