5 ms·

Writing a service file is trivial though

by nightfly 3y ago

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
        bandrami 3y ago
        And I had a staticly compiled make that read /etc/rc.mk in my toy distribution in 1999; none of this is a groundbreaking idea. There were plenty of ways to do parallel startup in the oughts but admins rejected them because parallel startup is largely a bad idea. Start the services in the order I tell you to, one at a time, logging the results. Anything else will eventually bite you.
        ilyt 3y ago
        Well, since the 90's we had more than one core in the average machine. There is no reason parallel start would be problematic; I even got stuff working that needed network access to get creds for encrypted partition that was required for database to start and it was handled flawlessly. More than that, if for some reason that file system wasn't mounted it would be when I told systemd to start database, it would run the service retrieving the secrets, then the mount using it, then the DB. The worse story is with shutdown; by default most distros will cut ssh access before services are closed so if some of them hang you can't debug that remotely. But that's mostly bad settings rather than bad design of the daemon
        bandrami 3y ago
        I think you're definitely right that shutdown is the harder problem and it's one that init systems in general pay a lot less attention to, unfortunately. If the system has a problem coming up it often at least gets into a state where I can access it; if it hangs after being told to reboot, well... I once had to drive from Arlington VA to Seacaucus NJ to press a power button on a rack server in our datacenter, and I don't like that.
        __d 3y ago
        You couldn't use the DC's remote hands?
        bandrami 3y ago
  - bandrami 3y ago
    It's generally not; I've never understood the claim that either one is particularly "complicated". You either write a set of sh commands that start the service the way you want to or a unit file that has that shell command plus some random metadata crap about it. Neither of these options are particularly difficult and I've literally never understood why people want to die on either side of this hill. The pain point was never "generating a textual representation appropriate to the init system"; the problem was always the underlying startup and teardown of the service itself.
- al2o3cr 3y ago
  If the startup script "hasn't been updated in a long time" and you're scared of breaking it, why would you update the operating system to whatever FUTURE version actually drops support for SysV scripts?
  - nightfly 3y ago
    I'm a fairly cautious sysadmin but I can't say that replacing an init a script with a systemd service is something I'd be afraid of doing
  - Etheryte 3y ago
    Business requirements are never "just don't update this machine", you often have conflicting requirements where one piece of software has one set of requirements and another one has different ones. You often need to update systems to stay compliant with security requirements and those updates are generally non-negotiable.
- ilyt 3y ago
  DO you have actual experience in having problems converting init scripts to systemd or you're talking entirely out of your arse? From my experience yes, even the legacy stuff is easy enough to convert.
henearkr 3y ago
The compatibility layer had the benefit of letting you write your service once for both init systems.

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
      - bandrami 3y ago
        And I had a staticly compiled make that read /etc/rc.mk in my toy distribution in 1999; none of this is a groundbreaking idea. There were plenty of ways to do parallel startup in the oughts but admins rejected them because parallel startup is largely a bad idea. Start the services in the order I tell you to, one at a time, logging the results. Anything else will eventually bite you.
        ilyt 3y ago
        Well, since the 90's we had more than one core in the average machine. There is no reason parallel start would be problematic; I even got stuff working that needed network access to get creds for encrypted partition that was required for database to start and it was handled flawlessly. More than that, if for some reason that file system wasn't mounted it would be when I told systemd to start database, it would run the service retrieving the secrets, then the mount using it, then the DB. The worse story is with shutdown; by default most distros will cut ssh access before services are closed so if some of them hang you can't debug that remotely. But that's mostly bad settings rather than bad design of the daemon
        bandrami 3y ago
        I think you're definitely right that shutdown is the harder problem and it's one that init systems in general pay a lot less attention to, unfortunately. If the system has a problem coming up it often at least gets into a state where I can access it; if it hangs after being told to reboot, well... I once had to drive from Arlington VA to Seacaucus NJ to press a power button on a rack server in our datacenter, and I don't like that.
        __d 3y ago
        You couldn't use the DC's remote hands?
        bandrami 3y ago
- bandrami 3y ago
  It's generally not; I've never understood the claim that either one is particularly "complicated". You either write a set of sh commands that start the service the way you want to or a unit file that has that shell command plus some random metadata crap about it. Neither of these options are particularly difficult and I've literally never understood why people want to die on either side of this hill. The pain point was never "generating a textual representation appropriate to the init system"; the problem was always the underlying startup and teardown of the service itself.
al2o3cr 3y ago
If the startup script "hasn't been updated in a long time" and you're scared of breaking it, why would you update the operating system to whatever FUTURE version actually drops support for SysV scripts?
- nightfly 3y ago
  I'm a fairly cautious sysadmin but I can't say that replacing an init a script with a systemd service is something I'd be afraid of doing
- Etheryte 3y ago
  Business requirements are never "just don't update this machine", you often have conflicting requirements where one piece of software has one set of requirements and another one has different ones. You often need to update systems to stay compliant with security requirements and those updates are generally non-negotiable.
ilyt 3y ago
DO you have actual experience in having problems converting init scripts to systemd or you're talking entirely out of your arse? From my experience yes, even the legacy stuff is easy enough to convert.

henearkr 3y ago

The compatibility layer had the benefit of letting you write your service once for both init systems.