11 ms·

“Support for System V scripts now deprecated; will be removed in future release”

29 points by sweettea 3y ago

nubinetwork 3y ago
That's a bold strategy cotton, let's see how it plays out for them. ;-) But seriously, I expect to see a lot of software lose the ability to be run on systemd because they don't ship a service file.
- aftbit 3y ago
  I assume someone will introduce a compatibility shim, either at the systemd layer itself, or by running the software in a container.
  - Arnavion 3y ago
    They could just fork the sysv-generator and continue maintaining it. (Generators are arbitrary programs that generate systemd units at runtime dynamically. Eg fstab-generator parses /etc/fstab and generates .mount units. The sysv-generator generates a .service unit for each sysv init script it finds, and is what is being removed here. https://github.com/systemd/systemd/blob/main/src/sysv-generator/sysv-generator.c https://github.com/systemd/systemd/blob/main/src/sysv-genera... )
    - henearkr 3y ago
      I'd even dare say: it'll be safer in other hands.
    - yjftsjthsd-h 3y ago
      Of course, that begs the question of why it's being removed in the first place; if it's really that modular, it shouldn't be any effort to maintain.
      - ilyt 3y ago
        The answer is they don't want to be ones maintaining it; after majority of distros migrated it's just a wasted effort on their part. Distros that use it can maintain it for their needs; it's pretty logical. There is very little reason for distro to support systemd and support sysv scripts. I am surprised it comes from red hat to be honest, if anything I'd imagine them needing it for some legacy software their customers use that might come only with init scripts. Then again, in most cases rewriting init script to run as systemd unit is very straightforward; but then I saw some fucked up init scripts too, like ones trying to start and manage multiple services at once (here hearthy "fuck you" to packetfence developer that thought that would be a good idea)
        yjftsjthsd-h 3y ago
        > it's just a wasted effort on their part I guess my naive expectation is that it should be any effort, hence the question. > Then again, in most cases rewriting init script to run as systemd unit is very straightforward; but then I saw some fucked up init scripts too, like ones trying to start and manage multiple services at once (here hearthy "fuck you" to packetfence developer that thought that would be a good idea) LOL, now you've triggered an old memory of IBM WebSphere MQ and its... charming init scripts. It was almost easy to replace them with service files, except that IIRC template unit files can only use one variable to template and we needed two, so I did something ugly. (I don't even remember what, just the gross feeling.)
        ilyt 3y ago
        one variable is the thing after @, IIRC called "instance" but you can use that variable to specify EnvironmentFile that has more variables :) and it also neatly get per-instance config into separate file or use configuration management to generate per-service files instead of using instances
        yjftsjthsd-h 3y ago
        > but you can use that variable to specify EnvironmentFile that has more variables :) I mean, you could, but when you really only had 2 variables that feels pretty kludgy. > or use configuration management to generate per-service files instead of using instances I suspect that's what I actually did, since ansible/chef/puppet/whatever is happy to nest for loops and template the result. It was just annoying that I couldn't do it in place.
  - op00to 3y ago
    It’s trivial to execute an existing script from a SystemD service. Like, you just tell the service to run the script. This is so much nothing it can’t get nothinger.
- JohnFen 3y ago
  My fear is that software will stop shipping with an init script option because of this. I really need to stop using Linux sooner rather than later.
  - overboard2 3y ago
    You could jump to Gentoo + OpenRC
  - henearkr 3y ago
    Or have a look at all the distros that don't use SystemD!
    - JohnFen 3y ago
      My fear is that more and more Linux software will depend on SystemD facilities directly.
  - lockhouse 3y ago
    The BSDs (Free,Net,Open, and Dragonfly) are excellent if you’re looking for an open source *nix that isn’t Linux.
    - shrubble 3y ago
      I am specifically working more with FreeBSD as I think the day is coming that Linux won't have the ease of configuration it does now.
    - JohnFen 3y ago
      Yes, I've been planning to move all my machines to BSD for a long while now. I've been procrastinating because I have a lot of machines and the scale of the task is a bit intimidating. The window for procrastination appears to be ending, though.
- nightfly 3y ago
  Writing a service file is trivial though
  - Etheryte 3y ago
    Updating software that hasn't been updated in a long time and so far worked just fine is not trivial though.
    - op00to 3y ago
      How is a SysV init script different than systemd starting that exact same script on the same system?
      - Arnavion 3y ago
        sysv init scripts are more complicated than just a list of commands to run to start the service. They have start / stop / reload functions and express dependencies. The sysv generator handles all of those. Like this jank: https://github.com/systemd/systemd/blob/08423f6d30f5db045b8a25307857f111f45ff292/src/sysv-generator/sysv-generator.c#L464-L476 https://github.com/systemd/systemd/blob/08423f6d30f5db045b8a... So it's not as simple as "Just write a .service with ExecStart=/etc/init.d/whatever start", but it's also not too complicated, especially if someone forks the sysv generator and keeps it working like I said in another comment.
        bandrami 3y ago
        Well, wait: sysv scripts can express dependenices but they don't have to. The admin is totally free to just set the start and stop orders in the runlevels themselves (that's how the BSD world does it). Setting up a dependency system means you're just making a worse systemd and I've never really gotten the appeal of it.
        ilyt 3y ago
        Fun fact: Debian, thanks to those dependencies, had ability to start SysV services in parallel, before any of that fancy upstart/systemd happened. It just had batch job that solved the dependencies, ordered the init scripts numerically, and then started in batches all of those that started in same number (IIRC, there might've been a bit more fancy stuff there too). It was kind of worse systemd but systemd wasn't around back then
- op00to 3y ago
  A trained monkey can write a service file. There is no software that can start with a SysV script that isn’t easily ported to a service file.
- closeparen 3y ago
  As far as I know, plugging into init is the responsibility of the person packaging the software for a particular distribution. If a package for your distro is not available and you're just compiling from source or downloading a standalone executable, you have to write your own anyways. It might be different if I were an experienced bash scripting guy, but I find chucking the path to the thing an "ExecStart" line a lot more straightforward then writing a script that parses arguments and calls start-stop-daemon and all that.
- gerdesj 3y ago
  I've used Linux for a couple of decades or so. SysV initscripts have been a pain for many of those years. Do you do RH/Mandrake/Mandriva flavoured or the SuSE ones and other oddities. I decided to wander over to Gentoo for my personal stuff for a decade or so. Now the bloody initscripts need to conform to OpenRC. At least Mr Marples gave me some help with this. A systemd unit is a simple thing to rustle up. I have recently been informed that an OpenRC script is too these days and I'll fiddle up a VM and have another bash with Gentoo. My job as Managing Director of my company is to maintain an open mind! I don't think that not shipping a systemd unit will crap out any piece of software. I've seen quite a few packages of code, source and that and an initscript in ./contrib probably works on Debian and farts loudly on SuSE or vv. Who cares? systemd can run it quite easily and with minimal pissing around. With logging and all the other useful stuff.
- kaba0 3y ago
  So they cease to exist for linuxes? Because there is no sizeable init system besides systemd.
shrubble 3y ago
Not made by Microsoft, but 'embrace, extend, extinguish' which is a strategy of these folks I saw coming years ago, will no doubt surprise many...
- not_your_vase 3y ago
  > Not made by Microsoft Poettering has been a Microsoft employee for like a year now.
- aftbit 3y ago
  Yeah I think we all saw it coming. At least kdbus didn't happen.
- op00to 3y ago
  … you’re mourning SysV init scripts? why?
  - BirAdam 3y ago
    Because it will one day be “invented” again as a “scriptable init”
  - cellularmitosis 3y ago
    I mourn it. I've been typing '/etc/init.d/apache2 restart' for about twenty years now. Why change it? Would it really be that hard to have a symlink from /etc/init.d/apache2 to /bin/systemctl and teach systemctl to do the right thing?
    - viraptor 3y ago
      There's a generic wrapper which existed for many years "service apache2 restart" will work regardless of the init type. You can also put "systemctl $1 apache2" in /etc/init.d/apache2 and keep using it. It's really not a big issue.
    - kaba0 3y ago
      Be the change you want to see.
aftbit 3y ago
Also they are ending support for unmerged-usr (/usr/bin and /bin as different directories). On one hand, here's Redhat (and Pottering) using their position as dominate service manager to bully distros and software into adopting their views of the world. On the other hand, systemd has been a great step away from fragmentation in distro-land.
- henearkr 3y ago
  > step away from fragmentation Not really, it has increased the number of people using alternative init systems like OpenRC, Runit, S6, etc. Before SystemD, SysV was even more mainstream than SystemD is today.
  - freedomben 3y ago
    That does not match my memory. I remember it being very split between Upstart and SysV. Now the major distros have pretty much all standardized on systemd.
    - henearkr 3y ago
      But Gentoo switched to OpenRC, Debian forked to Devuan, Arch forked to Artix: all these main distros were using SysV and now a part of their users are using an alternative system.
      - anonbanker 3y ago
        still using init scripts on OpenRC.
      - freedomben 3y ago
        What's the market share of those though? I've networked with a lot of devops/sysadmins and I can't to my recollection ever remember somebody using Devuan or Artix, and it's rare indeed to hear somebody using Gentoo. I'm not dismissing them because they aren't popular, but I do think it's not very reasonable to call the market fragmented when the nons are such a small percentage of overall use.
Arnavion 3y ago
It's just as well. There isn't any software on my OpenSUSE Tumbleweed (rolling distro) machines that still only has sysv scripts. My Debian 11 router had some (nginx IIRC) but those went away when I updated it to Debian 12. The more impactful change to me is the one mentioned a few lines down, about `systemctl --user` getting `CAP_WAKE_ALARM` so that user-privilege programs can set timers to wake up from suspend. As it mentions, GNOME Clocks has wanted to use systemd timers for a long time, and it's the de facto alarm program for Linux phones running GNOME / Phosh. https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests/146 https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests...
andrewstuart 3y ago
Lennart Poettering is now working for Microsoft. is he still working on systemd?
- Zambyte 3y ago
  He made the commit that added this deprecation notice https://github.com/systemd/systemd/commit/7474097d51907c5cc157a59f311e54949bdd6dba https://github.com/systemd/systemd/commit/7474097d51907c5cc1...
dsr_ 3y ago
$ ls -al /sbin/init -rwxr-xr-x 1 root root 52400 Apr 3 02:25 /sbin/init $ cat /etc/debian_version 12.0 running: postgresql, postfix, dovecot, clamav, nginx, chrony, clamav, isc-dhcpd, bind...
atomicnumber3 3y ago
I continue to be baffled by people objecting to systemd. I know some people just don't like it and that's fine, people make alternative distros without it. You're not alone. But I just have to ask, even if it sounds condescending (I'm sorry- but I really am just honestly baffled-) has anyone who complains about systemd actually written a unit file vs an init script? I have used init scripts, I have written init scripts. I hated it. Every program needed it's own little way of doing things and writing an init script for a daemon was a hassle of bash scripting and copy pasting. Now you can get so much functionality out of literally just an ExecStart with a few lines of boilerplate. It's beautiful. And all your logs are in journald, which for me get scraped by a single promtail config into Loki. And systemd's structured logging means I get a lot of metadata available by default for filtering and tagging. It's just swell. And it's free software!
- ed25519FUUU 3y ago
  I also never understood the disdain for it. I feel like 15 minutes of reading about systemd keywords and I was on my way to making some very usable and reliable systemd scripts. I don’t use sysv init anymore but I don’t feel like I ever fully understood those scripts.
  - foobarian 3y ago
    I get the disdain. Beyond just reacting to change, systemv is fully scripted and thus a lot more accessible - one can read the source and understand what is happening fully once the kernel is done. On the other hand with systemd I feel we get this opaque magical complexity encroaching into previously fully grokkable user space and that is very hard to take, regardless of actual pros and cons.
- mackal 3y ago
  I think it all comes back to people being upset about the Ubuntu PulseAudio switch. Ubuntu did a bad job when they switched to PulseAudio and caused lots of issues. Lennart Poettering was lead dev for both projects and it's weird how much the anti-systemd crowd get their panties in a bunch over him and also PA.
anonbanker 3y ago
[flagged]
nazgulsenpai 3y ago
Two things that are sure to set fire to the comment section: a negative article about Apple, and any article about systemd. Good luck out there, friends.
- bitwize 3y ago
  Don't forget Wayland!
rektide 3y ago
This is an amazing release. As far as controversy clickbait topics go, personally I'm much sadder to see umerged-usr bite the dust, even though i'm a huge fan of merged-usr, just because it was super nice being able to boot off whatever / you have and drop another systems' /usr in. But at least there's systemd-sysext to allow some combining overlays. Anyhow, excited to talk through various changes that look exceptionally neat to me: RootEphemeral=, which lets processes run in a filesystem snapshot; super neat for seeing what changes a process might make to your system. https://github.com/binpash/try https://github.com/binpash/try was a popular submission a couple days ago, & this builds in a similar capability to the os. RestartSteps= and RestartMaxDelaySec= to finally finally offer some level of control over exponential-backoff in the restart behavior. FileDescriptorStorePreserve= is kind of mysterious, lets systemd store open file descriptors for a process even after it terminates. Some interaction with systemd-analyze. Not sure what this is for exactly but definitely cool extra visibility/observability of processes. I tend to think it also potentially could be useful allow for some weird/fun stuff like restarting services without closing ports. Soft-reboot which can be useful for switching roots without having to juggle bootloading. Very useful for anyone doing partitioning or what-not. And as I hinted above, you can pass file-descriptors, meaning you can avoid service-interruption while rebooting; what a neat trick. DelegateSubgroup= puts processes inside a sub-cgroup inside the top level cgroup. So as a user you could have a bunch of sub-cgroups that you can manage, letting you juggle/manage resources within your cgroup. This sounds a lot like Dixon's incredible talk technique of cgroup management, Linux memory management at scale. https://www.youtube.com/watch?v=beefUhRH5lU&t=2241s https://www.youtube.com/watch?v=beefUhRH5lU&t=2241s This is also easily what I think the worst most pitiful saddest part of the Kubernetes story is: a complete unwillingness to let Linux manage memory & use cgroups well, in favor of it's own scheduler which makes all the decisions. iocost calculations for io devices, to configure/tune io/qos cost for devices. has a huge existing db of drives. https://github.com/iocost-benchmark/iocost-benchmarks https://github.com/iocost-benchmark/iocost-benchmarks systemd-sysext gains a systemd-confext twin. the former manages overlays for /usr and /opt, the latter manages overlays for /etc. Very nice portable services tool now. Maybe the capstone work completing Revisiting how we put together Linux Systems. https://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html https://0pointer.net/blog/revisiting-how-we-put-together-lin... . Using efi vars to save the hibernation partition, which should be a huge win for hibernation working everywhere. Some other neat bits: CAP_WAKE_ALARM rights to user sessions, for setting long-running timers. Sigqueue support to send processes signals with associate values. list-paths verb to show paths. systemd.tty.* kernel arguments for setting up ttys. Early load virtio_console module if it detects it's runnin in a VM to get console up earlier. Upholds= gets a new .upholds/ drop-in directory for keeping other services running (not just starting them like Wants=). sd_journal_get_seqnum api call so apps can have mechanistic sympathy with journald. Ton of bootloader, boot-security, repartitioning, disk-encryption enhancements across the map. SetTTY to for updating the TTY of a session; so useful for ssh'ing in. udev creates /dev/loop/by-ref/* files with helpful names. systemd-resolved gets a StateRetentionSec= to let you cache & use old records if a nameserver isn't responding. Most systemd services now have some standard signals they accept to tweak config, ex: changing log level, log target, trim memory, print debug mem info. machinectl & networkctl gain "edit" and "cat" capabilities for viewing config. systemd-firstboot --reset which is hella useful for cloning machines & updating machine-id. Services now sd_notify with their EXIT_STATUS on exit; part of trend of making services more observable/operable everywhere. new systemd.mount-extra= kernel arg to ask for mounts at startup. I love reading release notes in general, but this was absurdly delightful. It felt like in the past sometimes systemd was focusing on new feature growth & ideas, but I'm seeing huge maturation & growing in in this release. Really leaning hard into everything alive & responsive on via signals and passing around file-descriptors is excellent excellent excellent systems-wonkery. The fit and finish here is going way up. There's just a ton of damned-useful ergonomic wins that make everything super easy to find & see & touch & manage. 254 is an epic release.

29 points by sweettea 3y ago

That's a bold strategy cotton, let's see how it plays out for them. ;-) But seriously, I expect to see a lot of software lose the ability to be run on systemd because they don't ship a service file.

aftbit 3y ago
I assume someone will introduce a compatibility shim, either at the systemd layer itself, or by running the software in a container.
- Arnavion 3y ago
  They could just fork the sysv-generator and continue maintaining it. (Generators are arbitrary programs that generate systemd units at runtime dynamically. Eg fstab-generator parses /etc/fstab and generates .mount units. The sysv-generator generates a .service unit for each sysv init script it finds, and is what is being removed here. https://github.com/systemd/systemd/blob/main/src/sysv-generator/sysv-generator.c https://github.com/systemd/systemd/blob/main/src/sysv-genera... )
  - henearkr 3y ago
    I'd even dare say: it'll be safer in other hands.
  - yjftsjthsd-h 3y ago
    Of course, that begs the question of why it's being removed in the first place; if it's really that modular, it shouldn't be any effort to maintain.
    - ilyt 3y ago
      The answer is they don't want to be ones maintaining it; after majority of distros migrated it's just a wasted effort on their part. Distros that use it can maintain it for their needs; it's pretty logical. There is very little reason for distro to support systemd and support sysv scripts. I am surprised it comes from red hat to be honest, if anything I'd imagine them needing it for some legacy software their customers use that might come only with init scripts. Then again, in most cases rewriting init script to run as systemd unit is very straightforward; but then I saw some fucked up init scripts too, like ones trying to start and manage multiple services at once (here hearthy "fuck you" to packetfence developer that thought that would be a good idea)
      - yjftsjthsd-h 3y ago
        > it's just a wasted effort on their part I guess my naive expectation is that it should be any effort, hence the question. > Then again, in most cases rewriting init script to run as systemd unit is very straightforward; but then I saw some fucked up init scripts too, like ones trying to start and manage multiple services at once (here hearthy "fuck you" to packetfence developer that thought that would be a good idea) LOL, now you've triggered an old memory of IBM WebSphere MQ and its... charming init scripts. It was almost easy to replace them with service files, except that IIRC template unit files can only use one variable to template and we needed two, so I did something ugly. (I don't even remember what, just the gross feeling.)
        ilyt 3y ago
        one variable is the thing after @, IIRC called "instance" but you can use that variable to specify EnvironmentFile that has more variables :) and it also neatly get per-instance config into separate file or use configuration management to generate per-service files instead of using instances
        yjftsjthsd-h 3y ago
        > but you can use that variable to specify EnvironmentFile that has more variables :) I mean, you could, but when you really only had 2 variables that feels pretty kludgy. > or use configuration management to generate per-service files instead of using instances I suspect that's what I actually did, since ansible/chef/puppet/whatever is happy to nest for loops and template the result. It was just annoying that I couldn't do it in place.
- op00to 3y ago
  It’s trivial to execute an existing script from a SystemD service. Like, you just tell the service to run the script. This is so much nothing it can’t get nothinger.
JohnFen 3y ago
My fear is that software will stop shipping with an init script option because of this. I really need to stop using Linux sooner rather than later.
- overboard2 3y ago
  You could jump to Gentoo + OpenRC
- henearkr 3y ago
  Or have a look at all the distros that don't use SystemD!
  - JohnFen 3y ago
    My fear is that more and more Linux software will depend on SystemD facilities directly.
- lockhouse 3y ago
  The BSDs (Free,Net,Open, and Dragonfly) are excellent if you’re looking for an open source *nix that isn’t Linux.
  - shrubble 3y ago
    I am specifically working more with FreeBSD as I think the day is coming that Linux won't have the ease of configuration it does now.
  - JohnFen 3y ago
    Yes, I've been planning to move all my machines to BSD for a long while now. I've been procrastinating because I have a lot of machines and the scale of the task is a bit intimidating. The window for procrastination appears to be ending, though.
nightfly 3y ago
Writing a service file is trivial though
- Etheryte 3y ago
  Updating software that hasn't been updated in a long time and so far worked just fine is not trivial though.
  - op00to 3y ago
    How is a SysV init script different than systemd starting that exact same script on the same system?
    - Arnavion 3y ago
      sysv init scripts are more complicated than just a list of commands to run to start the service. They have start / stop / reload functions and express dependencies. The sysv generator handles all of those. Like this jank: https://github.com/systemd/systemd/blob/08423f6d30f5db045b8a25307857f111f45ff292/src/sysv-generator/sysv-generator.c#L464-L476 https://github.com/systemd/systemd/blob/08423f6d30f5db045b8a... So it's not as simple as "Just write a .service with ExecStart=/etc/init.d/whatever start", but it's also not too complicated, especially if someone forks the sysv generator and keeps it working like I said in another comment.
      - bandrami 3y ago
        Well, wait: sysv scripts can express dependenices but they don't have to. The admin is totally free to just set the start and stop orders in the runlevels themselves (that's how the BSD world does it). Setting up a dependency system means you're just making a worse systemd and I've never really gotten the appeal of it.
        ilyt 3y ago
        Fun fact: Debian, thanks to those dependencies, had ability to start SysV services in parallel, before any of that fancy upstart/systemd happened. It just had batch job that solved the dependencies, ordered the init scripts numerically, and then started in batches all of those that started in same number (IIRC, there might've been a bit more fancy stuff there too). It was kind of worse systemd but systemd wasn't around back then
op00to 3y ago
A trained monkey can write a service file. There is no software that can start with a SysV script that isn’t easily ported to a service file.
closeparen 3y ago
As far as I know, plugging into init is the responsibility of the person packaging the software for a particular distribution. If a package for your distro is not available and you're just compiling from source or downloading a standalone executable, you have to write your own anyways. It might be different if I were an experienced bash scripting guy, but I find chucking the path to the thing an "ExecStart" line a lot more straightforward then writing a script that parses arguments and calls start-stop-daemon and all that.
gerdesj 3y ago
I've used Linux for a couple of decades or so. SysV initscripts have been a pain for many of those years. Do you do RH/Mandrake/Mandriva flavoured or the SuSE ones and other oddities. I decided to wander over to Gentoo for my personal stuff for a decade or so. Now the bloody initscripts need to conform to OpenRC. At least Mr Marples gave me some help with this. A systemd unit is a simple thing to rustle up. I have recently been informed that an OpenRC script is too these days and I'll fiddle up a VM and have another bash with Gentoo. My job as Managing Director of my company is to maintain an open mind! I don't think that not shipping a systemd unit will crap out any piece of software. I've seen quite a few packages of code, source and that and an initscript in ./contrib probably works on Debian and farts loudly on SuSE or vv. Who cares? systemd can run it quite easily and with minimal pissing around. With logging and all the other useful stuff.
kaba0 3y ago
So they cease to exist for linuxes? Because there is no sizeable init system besides systemd.

shrubble 3y ago

Not made by Microsoft, but 'embrace, extend, extinguish' which is a strategy of these folks I saw coming years ago, will no doubt surprise many...

not_your_vase 3y ago
> Not made by Microsoft Poettering has been a Microsoft employee for like a year now.
aftbit 3y ago
Yeah I think we all saw it coming. At least kdbus didn't happen.
op00to 3y ago
… you’re mourning SysV init scripts? why?
- BirAdam 3y ago
  Because it will one day be “invented” again as a “scriptable init”
- cellularmitosis 3y ago
  I mourn it. I've been typing '/etc/init.d/apache2 restart' for about twenty years now. Why change it? Would it really be that hard to have a symlink from /etc/init.d/apache2 to /bin/systemctl and teach systemctl to do the right thing?
  - viraptor 3y ago
    There's a generic wrapper which existed for many years "service apache2 restart" will work regardless of the init type. You can also put "systemctl $1 apache2" in /etc/init.d/apache2 and keep using it. It's really not a big issue.
  - kaba0 3y ago
    Be the change you want to see.

aftbit 3y ago

Also they are ending support for unmerged-usr (/usr/bin and /bin as different directories). On one hand, here's Redhat (and Pottering) using their position as dominate service manager to bully distros and software into adopting their views of the world. On the other hand, systemd has been a great step away from fragmentation in distro-land.

henearkr 3y ago
> step away from fragmentation Not really, it has increased the number of people using alternative init systems like OpenRC, Runit, S6, etc. Before SystemD, SysV was even more mainstream than SystemD is today.
- freedomben 3y ago
  That does not match my memory. I remember it being very split between Upstart and SysV. Now the major distros have pretty much all standardized on systemd.
  - henearkr 3y ago
    But Gentoo switched to OpenRC, Debian forked to Devuan, Arch forked to Artix: all these main distros were using SysV and now a part of their users are using an alternative system.
    - anonbanker 3y ago
      still using init scripts on OpenRC.
    - freedomben 3y ago
      What's the market share of those though? I've networked with a lot of devops/sysadmins and I can't to my recollection ever remember somebody using Devuan or Artix, and it's rare indeed to hear somebody using Gentoo. I'm not dismissing them because they aren't popular, but I do think it's not very reasonable to call the market fragmented when the nons are such a small percentage of overall use.

Arnavion 3y ago

It's just as well. There isn't any software on my OpenSUSE Tumbleweed (rolling distro) machines that still only has sysv scripts. My Debian 11 router had some (nginx IIRC) but those went away when I updated it to Debian 12. The more impactful change to me is the one mentioned a few lines down, about `systemctl --user` getting `CAP_WAKE_ALARM` so that user-privilege programs can set timers to wake up from suspend. As it mentions, GNOME Clocks has wanted to use systemd timers for a long time, and it's the de facto alarm program for Linux phones running GNOME / Phosh. https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests/146 https://gitlab.gnome.org/GNOME/gnome-clocks/-/merge_requests...

andrewstuart 3y ago

Lennart Poettering is now working for Microsoft. is he still working on systemd?

Zambyte 3y ago
He made the commit that added this deprecation notice https://github.com/systemd/systemd/commit/7474097d51907c5cc157a59f311e54949bdd6dba https://github.com/systemd/systemd/commit/7474097d51907c5cc1...

dsr_ 3y ago

$ ls -al /sbin/init -rwxr-xr-x 1 root root 52400 Apr 3 02:25 /sbin/init $ cat /etc/debian_version 12.0 running: postgresql, postfix, dovecot, clamav, nginx, chrony, clamav, isc-dhcpd, bind...

atomicnumber3 3y ago

I continue to be baffled by people objecting to systemd. I know some people just don't like it and that's fine, people make alternative distros without it. You're not alone. But I just have to ask, even if it sounds condescending (I'm sorry- but I really am just honestly baffled-) has anyone who complains about systemd actually written a unit file vs an init script? I have used init scripts, I have written init scripts. I hated it. Every program needed it's own little way of doing things and writing an init script for a daemon was a hassle of bash scripting and copy pasting. Now you can get so much functionality out of literally just an ExecStart with a few lines of boilerplate. It's beautiful. And all your logs are in journald, which for me get scraped by a single promtail config into Loki. And systemd's structured logging means I get a lot of metadata available by default for filtering and tagging. It's just swell. And it's free software!

ed25519FUUU 3y ago
I also never understood the disdain for it. I feel like 15 minutes of reading about systemd keywords and I was on my way to making some very usable and reliable systemd scripts. I don’t use sysv init anymore but I don’t feel like I ever fully understood those scripts.
- foobarian 3y ago
  I get the disdain. Beyond just reacting to change, systemv is fully scripted and thus a lot more accessible - one can read the source and understand what is happening fully once the kernel is done. On the other hand with systemd I feel we get this opaque magical complexity encroaching into previously fully grokkable user space and that is very hard to take, regardless of actual pros and cons.
mackal 3y ago
I think it all comes back to people being upset about the Ubuntu PulseAudio switch. Ubuntu did a bad job when they switched to PulseAudio and caused lots of issues. Lennart Poettering was lead dev for both projects and it's weird how much the anti-systemd crowd get their panties in a bunch over him and also PA.

anonbanker 3y ago

[flagged]

nazgulsenpai 3y ago

Two things that are sure to set fire to the comment section: a negative article about Apple, and any article about systemd. Good luck out there, friends.

bitwize 3y ago
Don't forget Wayland!

rektide 3y ago

This is an amazing release. As far as controversy clickbait topics go, personally I'm much sadder to see umerged-usr bite the dust, even though i'm a huge fan of merged-usr, just because it was super nice being able to boot off whatever / you have and drop another systems' /usr in. But at least there's systemd-sysext to allow some combining overlays. Anyhow, excited to talk through various changes that look exceptionally neat to me: RootEphemeral=, which lets processes run in a filesystem snapshot; super neat for seeing what changes a process might make to your system. https://github.com/binpash/try https://github.com/binpash/try was a popular submission a couple days ago, & this builds in a similar capability to the os. RestartSteps= and RestartMaxDelaySec= to finally finally offer some level of control over exponential-backoff in the restart behavior. FileDescriptorStorePreserve= is kind of mysterious, lets systemd store open file descriptors for a process even after it terminates. Some interaction with systemd-analyze. Not sure what this is for exactly but definitely cool extra visibility/observability of processes. I tend to think it also potentially could be useful allow for some weird/fun stuff like restarting services without closing ports. Soft-reboot which can be useful for switching roots without having to juggle bootloading. Very useful for anyone doing partitioning or what-not. And as I hinted above, you can pass file-descriptors, meaning you can avoid service-interruption while rebooting; what a neat trick. DelegateSubgroup= puts processes inside a sub-cgroup inside the top level cgroup. So as a user you could have a bunch of sub-cgroups that you can manage, letting you juggle/manage resources within your cgroup. This sounds a lot like Dixon's incredible talk technique of cgroup management, Linux memory management at scale. https://www.youtube.com/watch?v=beefUhRH5lU&t=2241s https://www.youtube.com/watch?v=beefUhRH5lU&t=2241s This is also easily what I think the worst most pitiful saddest part of the Kubernetes story is: a complete unwillingness to let Linux manage memory & use cgroups well, in favor of it's own scheduler which makes all the decisions. iocost calculations for io devices, to configure/tune io/qos cost for devices. has a huge existing db of drives. https://github.com/iocost-benchmark/iocost-benchmarks https://github.com/iocost-benchmark/iocost-benchmarks systemd-sysext gains a systemd-confext twin. the former manages overlays for /usr and /opt, the latter manages overlays for /etc. Very nice portable services tool now. Maybe the capstone work completing Revisiting how we put together Linux Systems. https://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html https://0pointer.net/blog/revisiting-how-we-put-together-lin... . Using efi vars to save the hibernation partition, which should be a huge win for hibernation working everywhere. Some other neat bits: CAP_WAKE_ALARM rights to user sessions, for setting long-running timers. Sigqueue support to send processes signals with associate values. list-paths verb to show paths. systemd.tty.* kernel arguments for setting up ttys. Early load virtio_console module if it detects it's runnin in a VM to get console up earlier. Upholds= gets a new .upholds/ drop-in directory for keeping other services running (not just starting them like Wants=). sd_journal_get_seqnum api call so apps can have mechanistic sympathy with journald. Ton of bootloader, boot-security, repartitioning, disk-encryption enhancements across the map. SetTTY to for updating the TTY of a session; so useful for ssh'ing in. udev creates /dev/loop/by-ref/* files with helpful names. systemd-resolved gets a StateRetentionSec= to let you cache & use old records if a nameserver isn't responding. Most systemd services now have some standard signals they accept to tweak config, ex: changing log level, log target, trim memory, print debug mem info. machinectl & networkctl gain "edit" and "cat" capabilities for viewing config. systemd-firstboot --reset which is hella useful for cloning machines & updating machine-id. Services now sd_notify with their EXIT_STATUS on exit; part of trend of making services more observable/operable everywhere. new systemd.mount-extra= kernel arg to ask for mounts at startup. I love reading release notes in general, but this was absurdly delightful. It felt like in the past sometimes systemd was focusing on new feature growth & ideas, but I'm seeing huge maturation & growing in in this release. Really leaning hard into everything alive & responsive on via signals and passing around file-descriptors is excellent excellent excellent systems-wonkery. The fit and finish here is going way up. There's just a ton of damned-useful ergonomic wins that make everything super easy to find & see & touch & manage. 254 is an epic release.