5 ms·

> Support for System V service scripts is deprecated and will be removed in v260 All the services you forgot you were running for ten whole years, will fail t

by nix0n 9mo ago

> Support for System V service scripts is deprecated and will be removed in v260 All the services you forgot you were running for ten whole years, will fail to launch someday soon.

nish__ 9mo ago
How hard is it to just call your init.d scripts from a systemd unit?
- bonzini 9mo ago
  Not only it's easy, the exact contents of the systemd unit can already be found in /run/systemd/system.
  - nish__ 9mo ago
    Honestly. I'm sick of people complaining about systemd.
    - nottorp 9mo ago
      Were you paid to learn it? Because last time I wrote systemd units it looked like a job. Also, way over complex for anything but a multi user multi service server. The kind you're paid to maintain.
      - tapoxi 9mo ago
        Why would a server use a different init system than a desktop or embedded device? Why wouldn't you want unit files instead of much larger init shell scripts which duplicate logic across every service? It also enabled a ton of event driven actions which laptops/desktops/embedded devices use.
        bonzini 9mo ago
        > Why wouldn't you want unit files instead of much larger init shell scripts which duplicate logic across every service? Indeed, that criticism makes no sense at all. > It also enabled a ton of event driven actions which laptops/desktops/embedded devices use. Don't forget VMs. Even in server space, they use hotplug/hotunplug as much as traditional desktops.
        throw0101a 9mo ago
        >> It also enabled a ton of event driven actions which laptops/desktops/embedded devices use. > Don't forget VMs. Even in server space, they use hotplug/hotunplug as much as traditional desktops. I was doing hot plugging of hardware awo+ decades ago when I still administered Solaris machines. IBM/mainframes has been doing it since forever. Even on Linux udevd existed before systemd did.
        yjftsjthsd-h 9mo ago
        > Why would a server use a different init system than a desktop or embedded device? The server and desktop have a lot more disk+RAM+CPU than the embedded device, to the point that running systemd on the low end of "just enough to run Linux" would be a pain. Outside embedded, though, it probably works uniformly enough.
        nottorp 9mo ago
        Heh. I still have a pre systemd machine around. It uses 300 M of RAM for the OS and a few services I use in my home. I recently set up a "modern" systemd based Ubuntu server in a VM and it used closer to 1 G before I installed any service.
        op00to 9mo ago
        Why compare a "full-featured", do-everything OS like Ubuntu with something pre-systemd when you're concerned about memory consumption? I just checked a random debian 12 system (with systemd) running a bunch of services at home, and here's what I see: $ free -m total used free shared buff/cache available Mem: 3791 320 2235 1 1313 3471 Swap: 99 0 99 Seems like usage is pretty much on par with your expectation. The largest consumers are systemd-journal which is storing logs in RAM, and filebeat which is relatively wasteful w/ memory. systemd itself (without the journal buffer log) consumes maybe 20-30 MB.
      - 0x457 9mo ago
        > a multi user multi service server. The kind you're paid to maintain. TIL. Didn't know I can get paid to maintain my PC because I have a background service that does not run as my admin user.
      - bigstrat2003 9mo ago
        I think you're way overstating things. Systemd units can be complex, but for most things they are dead simple to write.
      - nailer 9mo ago
        > Because last time I wrote systemd units it looked like a job. Fascinating. Last time I wrote a .service file I thought how muhc easier it was than a SysV init script.
        egorfine 9mo ago
        Until you need to actually dive deep into complicated scenarios. In sysv init you were on your own, which could be for better or for worse. In the world of systemd you either do as LP says or you do not at all. I vastly prefer #1.
        ndsipa_pomu 9mo ago
        Why can't you just call a sysv init script (or other customised script) from a systemd service? I did this just the other day when I wanted to delay starting of docker/nfs-kernel-server until a DRBD disk was mounted. I found problems with doing it just using the standard systemd methods to delay start as having a prerequisite meant that the service would fail to start and not attempt to restart. My solution was to put together a script that would check for the existence of a file (located on the mounted DRBD disk) and sleep for 5 seconds if it didn't exist and as soon as the file did exist, it'd call the systemctl command to start docker etc. Systemd gives you both worlds.
        egorfine 9mo ago
        Personally I would just throw a script for this service as you have described. Commercially I would do my best to implement this using systemd features, then finally give up and throw a script but with extensive comments describing reasons why it has to be a script instead of a systemd unit file.
        ndsipa_pomu 9mo ago
        Well, my solution is a script and a systemd unit and timer files to run the script (the timer is just so that I can have it running 30 seconds after boot).
      - jauntywundrkind 9mo ago
        A systemd service can be: [Service] Type=simple ExecStart=/usr/bin/my-service If this is a hard job for you well maybe get another career mate. Especially now with LLMs. The thing to me is that services sometimes do have cause to be more complex, or more secure, or to be better managed in various ways. Over time we might find (for ex) oh actually waiting for this other service to be up and available first helps. And if you went to run a service in the past, you never know what you are going to get. Each service that came with (for ex) Debian was it's own thing. Many forked off from one template or a other. But often forked long ago, with their own idiosyncratic threads woven in over time. Complexity emerged, and it wasn't contained, and it crrtainly wasn't normalized complexity across services: there would be dozens of services each one requiring careful staring at an init script to understand, with slightly different operational characteristics and nuance. I find the complaints about systemd being complex almost always look at the problem in isolation. "I just want to run my (3 line) service, but I don't want to have to learn how systemd works & manages unit: this is complex!". But it ignores the sprawl of what's implied: that everyone else was out there doing whatever, and that you stumble in blind to all manners of bespoke homegrown complexity. Systemd offers a gradient of complexity, that begins with extremely simple (but still offering impressive management and oversight), and that lets services wade into more complexity as they need. I think it is absolutely humbling and to some people an affront to see man pages with so so so many options, that it's natural to say: I don't need this, this is complex. But given how easy it is, how much great ability to see the state of the world we get that SysV never offered, given the standard shared culture tools and means, and given the divergent evolutionary chaos of everyone muddling through init scripts themselves, systemd feels vastly more contained, learnable, useful, concise, and less complex than the nightmares of old. And it has simple starting points, as shown at the top, that you can add onto and embelish onwards as you find cause to move further along the gradient of complexity, and you can do so in a simple way. It's also incredibly awesome how many amazing tools for limiting process access, for sandboxing and securing services systemd has. The security wins can be enormous. > Because last time I wrote systemd units it looked like a job Last, an LLM will be able to help you with systemd, since it is common knowledge with common practice. If you really dislike having to learn anything.
        nottorp 9mo ago
      - deleted 9mo ago
        [deleted]
    - JCattheATM 9mo ago
      That's funny, because I'm sick of people glazing it and glossing over its many flaws.
sebazzz 9mo ago
For me it is quite a list. However, it is not easy figuring out which of those script are actually a SysVInit script and which simply wrap systemd.
- bonzini 9mo ago
  As I wrote in another comment, just check out /run/systemd/system. You'll find the wrapper units that systemd creates for your sysvinit scripts.
noosphr 9mo ago
Every release of redhat software makes me happy I switched to openbsd for my human scale computers.
sidewndr46 9mo ago
Wasn't this support listed as one of the reasons why systemD would be fine for everyone to adopt?
- deleted 9mo ago
  [deleted]
- bonzini 9mo ago
  That was almost 15 years ago and the support is evidently not as useful. Also it's entirely contained within a program that creates systemd .service files. It's super easy to extract it in a separate project. I bet someone will do it very quickly if there's need.

by nix0n 9mo ago

> Support for System V service scripts is deprecated and will be removed in v260 All the services you forgot you were running for ten whole years, will fail to launch someday soon.

nish__ 9mo ago

How hard is it to just call your init.d scripts from a systemd unit?

bonzini 9mo ago
Not only it's easy, the exact contents of the systemd unit can already be found in /run/systemd/system.
- nish__ 9mo ago
  Honestly. I'm sick of people complaining about systemd.
  - nottorp 9mo ago
    Were you paid to learn it? Because last time I wrote systemd units it looked like a job. Also, way over complex for anything but a multi user multi service server. The kind you're paid to maintain.
    - tapoxi 9mo ago
      Why would a server use a different init system than a desktop or embedded device? Why wouldn't you want unit files instead of much larger init shell scripts which duplicate logic across every service? It also enabled a ton of event driven actions which laptops/desktops/embedded devices use.
      - bonzini 9mo ago
        > Why wouldn't you want unit files instead of much larger init shell scripts which duplicate logic across every service? Indeed, that criticism makes no sense at all. > It also enabled a ton of event driven actions which laptops/desktops/embedded devices use. Don't forget VMs. Even in server space, they use hotplug/hotunplug as much as traditional desktops.
        throw0101a 9mo ago
        >> It also enabled a ton of event driven actions which laptops/desktops/embedded devices use. > Don't forget VMs. Even in server space, they use hotplug/hotunplug as much as traditional desktops. I was doing hot plugging of hardware awo+ decades ago when I still administered Solaris machines. IBM/mainframes has been doing it since forever. Even on Linux udevd existed before systemd did.
      - yjftsjthsd-h 9mo ago
        > Why would a server use a different init system than a desktop or embedded device? The server and desktop have a lot more disk+RAM+CPU than the embedded device, to the point that running systemd on the low end of "just enough to run Linux" would be a pain. Outside embedded, though, it probably works uniformly enough.
        nottorp 9mo ago
        Heh. I still have a pre systemd machine around. It uses 300 M of RAM for the OS and a few services I use in my home. I recently set up a "modern" systemd based Ubuntu server in a VM and it used closer to 1 G before I installed any service.
        op00to 9mo ago
        Why compare a "full-featured", do-everything OS like Ubuntu with something pre-systemd when you're concerned about memory consumption? I just checked a random debian 12 system (with systemd) running a bunch of services at home, and here's what I see: $ free -m total used free shared buff/cache available Mem: 3791 320 2235 1 1313 3471 Swap: 99 0 99 Seems like usage is pretty much on par with your expectation. The largest consumers are systemd-journal which is storing logs in RAM, and filebeat which is relatively wasteful w/ memory. systemd itself (without the journal buffer log) consumes maybe 20-30 MB.
    - 0x457 9mo ago
      > a multi user multi service server. The kind you're paid to maintain. TIL. Didn't know I can get paid to maintain my PC because I have a background service that does not run as my admin user.
    - bigstrat2003 9mo ago
      I think you're way overstating things. Systemd units can be complex, but for most things they are dead simple to write.
    - nailer 9mo ago
      > Because last time I wrote systemd units it looked like a job. Fascinating. Last time I wrote a .service file I thought how muhc easier it was than a SysV init script.
      - egorfine 9mo ago
        Until you need to actually dive deep into complicated scenarios. In sysv init you were on your own, which could be for better or for worse. In the world of systemd you either do as LP says or you do not at all. I vastly prefer #1.
        ndsipa_pomu 9mo ago
        Why can't you just call a sysv init script (or other customised script) from a systemd service? I did this just the other day when I wanted to delay starting of docker/nfs-kernel-server until a DRBD disk was mounted. I found problems with doing it just using the standard systemd methods to delay start as having a prerequisite meant that the service would fail to start and not attempt to restart. My solution was to put together a script that would check for the existence of a file (located on the mounted DRBD disk) and sleep for 5 seconds if it didn't exist and as soon as the file did exist, it'd call the systemctl command to start docker etc. Systemd gives you both worlds.
        egorfine 9mo ago
        Personally I would just throw a script for this service as you have described. Commercially I would do my best to implement this using systemd features, then finally give up and throw a script but with extensive comments describing reasons why it has to be a script instead of a systemd unit file.
        ndsipa_pomu 9mo ago
        Well, my solution is a script and a systemd unit and timer files to run the script (the timer is just so that I can have it running 30 seconds after boot).
    - jauntywundrkind 9mo ago
      A systemd service can be: [Service] Type=simple ExecStart=/usr/bin/my-service If this is a hard job for you well maybe get another career mate. Especially now with LLMs. The thing to me is that services sometimes do have cause to be more complex, or more secure, or to be better managed in various ways. Over time we might find (for ex) oh actually waiting for this other service to be up and available first helps. And if you went to run a service in the past, you never know what you are going to get. Each service that came with (for ex) Debian was it's own thing. Many forked off from one template or a other. But often forked long ago, with their own idiosyncratic threads woven in over time. Complexity emerged, and it wasn't contained, and it crrtainly wasn't normalized complexity across services: there would be dozens of services each one requiring careful staring at an init script to understand, with slightly different operational characteristics and nuance. I find the complaints about systemd being complex almost always look at the problem in isolation. "I just want to run my (3 line) service, but I don't want to have to learn how systemd works & manages unit: this is complex!". But it ignores the sprawl of what's implied: that everyone else was out there doing whatever, and that you stumble in blind to all manners of bespoke homegrown complexity. Systemd offers a gradient of complexity, that begins with extremely simple (but still offering impressive management and oversight), and that lets services wade into more complexity as they need. I think it is absolutely humbling and to some people an affront to see man pages with so so so many options, that it's natural to say: I don't need this, this is complex. But given how easy it is, how much great ability to see the state of the world we get that SysV never offered, given the standard shared culture tools and means, and given the divergent evolutionary chaos of everyone muddling through init scripts themselves, systemd feels vastly more contained, learnable, useful, concise, and less complex than the nightmares of old. And it has simple starting points, as shown at the top, that you can add onto and embelish onwards as you find cause to move further along the gradient of complexity, and you can do so in a simple way. It's also incredibly awesome how many amazing tools for limiting process access, for sandboxing and securing services systemd has. The security wins can be enormous. > Because last time I wrote systemd units it looked like a job Last, an LLM will be able to help you with systemd, since it is common knowledge with common practice. If you really dislike having to learn anything.
      - nottorp 9mo ago
    - deleted 9mo ago
      [deleted]
  - JCattheATM 9mo ago
    That's funny, because I'm sick of people glazing it and glossing over its many flaws.

sebazzz 9mo ago

For me it is quite a list. However, it is not easy figuring out which of those script are actually a SysVInit script and which simply wrap systemd.

bonzini 9mo ago
As I wrote in another comment, just check out /run/systemd/system. You'll find the wrapper units that systemd creates for your sysvinit scripts.

noosphr 9mo ago

Every release of redhat software makes me happy I switched to openbsd for my human scale computers.

sidewndr46 9mo ago

Wasn't this support listed as one of the reasons why systemD would be fine for everyone to adopt?

deleted 9mo ago
[deleted]
bonzini 9mo ago
That was almost 15 years ago and the support is evidently not as useful. Also it's entirely contained within a program that creates systemd .service files. It's super easy to extract it in a separate project. I bet someone will do it very quickly if there's need.