5 ms·

Actual announcement: https://devuan.org/os/debian-fork/stable-candidate-announce-042017 https://devuan.org/os/debian-fork/stable-candidate-announce-... Reminds

Actual announcement: https://devuan.org/os/debian-fork/stable-candidate-announce-042017 https://devuan.org/os/debian-fork/stable-candidate-announce-... Reminds me of dragonfly bsd. Anyone still use that? I stayed on 4.x until 6.x came out and later Scott Long actually admitted that 5.x was a bad release. So Devuan now wants to continue Debian with tons of shell scripts to maintain while most other major distros move to systemd. That means package maintainers are moving to systemd. So Devuan will have to maintain separate init scripts for their distro mostly on their own. I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit?

SwellJoe 10y ago
"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.
- JdeBP 10y ago
  As I pointed out at https://news.ycombinator.com/item?id=14169188 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/mariadb%40.service.in 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/systemd/mysqld.service.in 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/systemd/mysqld.service.in 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/apache2.service/ 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.
  - SwellJoe 10y ago
    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).
    - JdeBP 10y ago
      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/mysql.server.sh 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/mongodb/vivid/view/head:/debian/mongodb-server.mongodb.service http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/mo... * https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mongodb-server.mongodb.service/ https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mon... * https://docs.mongodb.com/manual/reference/ulimit/#linux-distributions-using-systemd 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 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 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#Prompt http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...
- peterwwillis 10y ago
  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)
  - vacri 10y ago
    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.
    - peterwwillis 10y ago
      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.
- INTPenis 10y ago
  >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.
mdekkers 10y ago
I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit? That is a gross and asinine misrepresentation of the impact of systemd.
- INTPenis 10y ago
  Not from my viewpoint. I'm the one installing the packages and writing the occasional unit/override unit in my daily work. I don't see those complex use cases systemd critics often point to. I mostly see the fact that I get to maintain a few lines of ini-style configuration instead of many lines of bash.
  - mdekkers 10y ago
    https://news.ycombinator.com/item?id=14175261 https://news.ycombinator.com/item?id=14175261
    - INTPenis 10y ago
      I'm sorry but those links are no good argument to me. I've already commented on the fact that MariaDB service unit is 173 lines of ini-style configuration with most of the lines commented for example purposes. So I'd still gladly trade many lines of bash for hundreds of lines of ini-config. And sure some projects still depend on shell script wrapping, I myself did for many python services that I run in virtualenv. But I learned more about systemd and eventually could get rid of all shell script wrappers. But even in a worst case scenario where some project might have to use shell script wrapping, it's still better than ALL projects using 100% shell script.
khedoros1 10y ago
> I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit? The person who already knows the one tool, but not the other, I suppose. Or who finds it easier to read a shell script than a new DSL.
peterwwillis 10y ago
I would actually be fine with using systemd to manage a few services. Does it no longer require itself to be pid 1 to function?

SwellJoe 10y ago

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

JdeBP 10y ago
As I pointed out at https://news.ycombinator.com/item?id=14169188 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/mariadb%40.service.in 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/systemd/mysqld.service.in 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/systemd/mysqld.service.in 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/apache2.service/ 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.
- SwellJoe 10y ago
  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).
  - JdeBP 10y ago
    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/mysql.server.sh 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/mongodb/vivid/view/head:/debian/mongodb-server.mongodb.service http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/mo... * https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mongodb-server.mongodb.service/ https://sources.debian.net/src/mongodb/1:3.2.11-2/debian/mon... * https://docs.mongodb.com/manual/reference/ulimit/#linux-distributions-using-systemd 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 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 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#Prompt http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...
peterwwillis 10y ago
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)
- vacri 10y ago
  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.
  - peterwwillis 10y ago
    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.
INTPenis 10y ago
>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.

mdekkers 10y ago

I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit? That is a gross and asinine misrepresentation of the impact of systemd.

INTPenis 10y ago
Not from my viewpoint. I'm the one installing the packages and writing the occasional unit/override unit in my daily work. I don't see those complex use cases systemd critics often point to. I mostly see the fact that I get to maintain a few lines of ini-style configuration instead of many lines of bash.
- mdekkers 10y ago
  https://news.ycombinator.com/item?id=14175261 https://news.ycombinator.com/item?id=14175261
  - INTPenis 10y ago
    I'm sorry but those links are no good argument to me. I've already commented on the fact that MariaDB service unit is 173 lines of ini-style configuration with most of the lines commented for example purposes. So I'd still gladly trade many lines of bash for hundreds of lines of ini-config. And sure some projects still depend on shell script wrapping, I myself did for many python services that I run in virtualenv. But I learned more about systemd and eventually could get rid of all shell script wrappers. But even in a worst case scenario where some project might have to use shell script wrapping, it's still better than ALL projects using 100% shell script.

khedoros1 10y ago

> I mean who in their right mind would write a 27 line init script when they could write a 7 line systemd unit? The person who already knows the one tool, but not the other, I suppose. Or who finds it easier to read a shell script than a new DSL.

peterwwillis 10y ago

I would actually be fine with using systemd to manage a few services. Does it no longer require itself to be pid 1 to function?