I would stay away from upstart because canonical. SysV, yes in the blink of an eye.
But you are mistaken if you think systemd is about init, it has gobbled so much stuff that this thing is a monstrous kitchen sink on its way to engulfing the whole bathroom.
then again maybe there are other init systems options than those two, devuan which arose from keeping systemd out of debian offert no less than 6 alternatives that address SysV flaws: openrc, sinit, runit, s6 and shepherd.
That is to say, there are quite a number of modern inits that are not systemd. It's such a straw-man argument to bring up sysv init every time someone says something critical of systemd.
Yet it comes up nearly every time I express concern about any aspect of systemd. ("Like it or not, you've got to move on from sysv; systemd is the industry standard" etc. etc.)
Yes, without question. Systemd provides me absolutely no benefit when running a server and adds considerable complexity and fragility in a critical component.
A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
So you're saying to just use SysV init to launch processes from inittab, and have one of those processes be a systemd/launchd clone that launches everything else. I mean, I guess that's a possible design, but at that point I would question whether using the SysV init program is really buying you anything.
In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
I teach unix internals to engineers as part of my job and I've found most engineers aren't intimately familiar with the distinction between the RC system and the init system at all. I agree there isn't widespread understanding of this distinction but I think it is because most engineers simply don't know how any of this works.
The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems.
I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't.
I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago.
System components need to be well scoped and replaceable. There's a major design problem brewing in this area.
It's not only possible, it is how the System Resource Controller worked in AIX from version 3.2 back in 1992 onwards. srcmstr is run from an entry in inittab, which at the same time shrank to just one run level in real use.
You have erroneously conflated rc and init, as others have pointed out.
I'd rathe someone take another shot at service management.
I don't want to hold onto everything about SysV style systems - I love SMF in Solaris! - but I'd definitely prefer a leaner and more focused approach to development than we see with systemd.
No, it was just a joke, you know... but in fact I've checked and I'm already running upstart right now, as part of my Ubuntu LTS system. So really no need to "go back" :P
Yes, it's 14.04. I tried 18.04 a couple of weeks ago, but I didn't really like the new GNOME interface. For me, Unity was (is) a great DE. I know other things improved too, but I'm not really enthusiastic about them either. For example, snaps, whose paradigm of self-contained applications I don't consider an improvement.
I would disagree that systemd got adopted because it had been already adopted, this is a circular reasoning.
From a distance it looks like politics and influence pushed for adoption of systemd, motivation behind this uncanny move and spread has been questioned making some wonder if this could be intended with a nefarious purpose in mind.
False dichotomy indeed. Right now I'm testing runit (on void linux) for my production machines. My experience since more than a year: Once it runs it runs, literally zero surprises so far.
The general volatility of systemd introduces so many unstable elements in your system, that it really makes you think if the added risk it is really worth the value it offers (even though I'm still not quiet sure what the value of systemd actually is).
I'm not exactly surprised that someone who isn't using systemd for anything is getting little value from it. If you really want to give it a fair chance go all in on 'the systemd way' and you'll wonder how you ever got by without it.
- Services can depend on mounts, sockets, paths, or other servives. Don't start the NFS server until your backend storage is online and mounted and stop it if it goes offline.
- Are you annoyed when Symantec is chewing through your CPU? Use systemctl --edit and cap it at 20% with one CPUQuota option.
- Have a NodeJS service you want to bind to port 80 but not run as root? AmbientCapabilities=CAP_NET_BIND_SERVICE and you're done.
- Want to automount a directory? Drop in an .automount file or add an option to fstab and you're done.
- Replace GRUB with systemd-boot and enjoy configuring boot options with simple INI files.
- Want to do offline updates? Have any service you want be part of system-update.target, touch /system-update and reboot.
- Annoyed that you can't have more than 3 dns servers or can't run DNSoTLS or DNSoHTTPS? systemd-resolved has your back.
- Forget about ntpd or chrony and use systemd-timesyncd is a lightweight standards complaint ntp client.
- Run all your userspace daemons like offlineimap, tmux, emacs, your dev server, etc. as systemd user services.
- Manage the permissions, resource usage, and monitor long running jobs with systemd-run.
- Replace cron with systemd timers that not only have more powerful timespecs, are hooked into the dependency solver, and can be monitored like any other service.
- Isolate troublesome 3rd party applications with systemd-portable which are a bit like privileged containers but easier to use.
- Run apps as unprivileged users without having to fill passwd with users and groups just for services with dynamic users.
These are just the ones off the top of my head. It boggles my mind how people say that systemd doesn't provide value.
I switched to Gentoo because of systemd. I switched to OpenBSD because Linus was recently 'compromised' and adopted the CoC (worse: it's the highly political Creator's Covenant version). Theo's philosophy is shut up and hack, much like the early Linus with the bonus of being security instead of performance oriented.
I'd love to see a Portage Prefix on OpenBSD, or Gentoo/kOpenBSD, effort start up again. Bringing Portage to OpenBSD (even if prefixed) would make a wonderful combination!
I would stay away from upstart because canonical. SysV, yes in the blink of an eye.
But you are mistaken if you think systemd is about init, it has gobbled so much stuff that this thing is a monstrous kitchen sink on its way to engulfing the whole bathroom.
then again maybe there are other init systems options than those two, devuan which arose from keeping systemd out of debian offert no less than 6 alternatives that address SysV flaws: openrc, sinit, runit, s6 and shepherd.
A: I'm not that fond of Ford cars.
B: So you want to drive a horse-and-buggy then?
That is to say, there are quite a number of modern inits that are not systemd. It's such a straw-man argument to bring up sysv init every time someone says something critical of systemd.
The false dichotomy was called out by the Uselessd Guy some years ago.
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Yet it comes up nearly every time I express concern about any aspect of systemd. ("Like it or not, you've got to move on from sysv; systemd is the industry standard" etc. etc.)
Yes, without question. Systemd provides me absolutely no benefit when running a server and adds considerable complexity and fragility in a critical component.
A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
So you're saying to just use SysV init to launch processes from inittab, and have one of those processes be a systemd/launchd clone that launches everything else. I mean, I guess that's a possible design, but at that point I would question whether using the SysV init program is really buying you anything.
In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
I teach unix internals to engineers as part of my job and I've found most engineers aren't intimately familiar with the distinction between the RC system and the init system at all. I agree there isn't widespread understanding of this distinction but I think it is because most engineers simply don't know how any of this works.
The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems.
I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't.
I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago.
System components need to be well scoped and replaceable. There's a major design problem brewing in this area.
2 replies →
It's not only possible, it is how the System Resource Controller worked in AIX from version 3.2 back in 1992 onwards. srcmstr is run from an entry in inittab, which at the same time shrank to just one run level in real use.
You have erroneously conflated rc and init, as others have pointed out.
I'd rathe someone take another shot at service management.
I don't want to hold onto everything about SysV style systems - I love SMF in Solaris! - but I'd definitely prefer a leaner and more focused approach to development than we see with systemd.
Then you should pick up the reins of System XVI.
* https://news.ycombinator.com/item?id=10212770
It is interesting that you bring up SMF. For me systemd mostly seems like saner implementation of SMF.
No, it was just a joke, you know... but in fact I've checked and I'm already running upstart right now, as part of my Ubuntu LTS system. So really no need to "go back" :P
Ubuntu switched to systemd from 16.04. You must be running 14.04. Ubuntu improved a lot in 4 years.
Yes, it's 14.04. I tried 18.04 a couple of weeks ago, but I didn't really like the new GNOME interface. For me, Unity was (is) a great DE. I know other things improved too, but I'm not really enthusiastic about them either. For example, snaps, whose paradigm of self-contained applications I don't consider an improvement.
Last I checked Upstart was deprecated.
It is, but it's also the init system of some Ubuntu versions still supported, so you can be running upstart on a modern, supported distribution.
1 reply →
False dichotomy. There are more options than those. SystemD won because it had been adopted already and was supported by a major company in FOSS
I would disagree that systemd got adopted because it had been already adopted, this is a circular reasoning.
From a distance it looks like politics and influence pushed for adoption of systemd, motivation behind this uncanny move and spread has been questioned making some wonder if this could be intended with a nefarious purpose in mind.
You just cannot call it "politics and influence" when systemd was discussed thoroughly and adopted by Debian.
2 replies →
False dichotomy indeed. Right now I'm testing runit (on void linux) for my production machines. My experience since more than a year: Once it runs it runs, literally zero surprises so far.
The general volatility of systemd introduces so many unstable elements in your system, that it really makes you think if the added risk it is really worth the value it offers (even though I'm still not quiet sure what the value of systemd actually is).
I'm not exactly surprised that someone who isn't using systemd for anything is getting little value from it. If you really want to give it a fair chance go all in on 'the systemd way' and you'll wonder how you ever got by without it.
- Services can depend on mounts, sockets, paths, or other servives. Don't start the NFS server until your backend storage is online and mounted and stop it if it goes offline.
- Are you annoyed when Symantec is chewing through your CPU? Use systemctl --edit and cap it at 20% with one CPUQuota option.
- Have a NodeJS service you want to bind to port 80 but not run as root? AmbientCapabilities=CAP_NET_BIND_SERVICE and you're done.
- Want to automount a directory? Drop in an .automount file or add an option to fstab and you're done.
- Replace GRUB with systemd-boot and enjoy configuring boot options with simple INI files.
- Want to do offline updates? Have any service you want be part of system-update.target, touch /system-update and reboot.
- Annoyed that you can't have more than 3 dns servers or can't run DNSoTLS or DNSoHTTPS? systemd-resolved has your back.
- Forget about ntpd or chrony and use systemd-timesyncd is a lightweight standards complaint ntp client.
- Run all your userspace daemons like offlineimap, tmux, emacs, your dev server, etc. as systemd user services.
- Manage the permissions, resource usage, and monitor long running jobs with systemd-run.
- Replace cron with systemd timers that not only have more powerful timespecs, are hooked into the dependency solver, and can be monitored like any other service.
- Isolate troublesome 3rd party applications with systemd-portable which are a bit like privileged containers but easier to use.
- Run apps as unprivileged users without having to fill passwd with users and groups just for services with dynamic users.
These are just the ones off the top of my head. It boggles my mind how people say that systemd doesn't provide value.
2 replies →
I switched to Gentoo because of systemd. I switched to OpenBSD because Linus was recently 'compromised' and adopted the CoC (worse: it's the highly political Creator's Covenant version). Theo's philosophy is shut up and hack, much like the early Linus with the bonus of being security instead of performance oriented.
I'd love to see a Portage Prefix on OpenBSD, or Gentoo/kOpenBSD, effort start up again. Bringing Portage to OpenBSD (even if prefixed) would make a wonderful combination!