4 ms·

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.