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.

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...