7 ms·

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

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.
        ilyt 3y ago
        well, instances weren't really done to customize variables, their design was pretty much to do "a program that can be given a different config file as a parameter", like it is done for say postgresql instances.
- 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.

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.
        ilyt 3y ago
        well, instances weren't really done to customize variables, their design was pretty much to do "a program that can be given a different config file as a parameter", like it is done for say postgresql instances.
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.