4 ms·

Init scripts are just executable files. They can be written in any compiled language you like or even an interpreted language, if you are prepared to add the d

Init scripts are just executable files. They can be written in any compiled language you like or even an interpreted language, if you are prepared to add the dependency of an interpreter for that language at boot time. This is a lot simpler than migrating to (and getting locked in to) systemd.

otabdeveloper4 6y ago
systemd is exactly the boot time interpreter you're asking for.
- corty 6y ago
  No, systemd doesn't really interpret much, unit files are mostly not a full replacement for what init-scripts were capable of. Which leads to lots of Exec=/some/shell/script.sh in unit files which is worse than before because now you have multiple files and more strange interactions.
  - BenjiWiebe 6y ago
    Is that actually common? I write quite a few systemd unit files, and have yet to need a wrapper shell script. And the vast majority, or maybe even all, of the unit files my system has by default are also not calling shell scripts.
    - alerighi 6y ago
      Depends on what you are doing. Init scripts where simpler because the boot process was well defined, meaning that you had all your scripts in rc.d that were executed in that particular order. Now with systemd is more difficult to have something start after something else, you have all the dependencies and if you get them wrong it will not work. Worse, the boot process is no longer deterministic, meaning that 99 times it could work and it could break the 100th time. On the other side, systemd is a necessary evil for a modern desktop system, where you have multiple events that could fire (hotplug, network, power events, etc). But not so sure if it's that necessary for a server or an embedded device.
      - otabdeveloper4 6y ago
        > Now with systemd is more difficult to have something start after something else Not really, it's just one simple line in a unit file. (https://fedoramagazine.org/systemd-unit-dependencies-and-order/ https://fedoramagazine.org/systemd-unit-dependencies-and-ord...)
        corty 6y ago
        No. First, you usually need both, Want= and After=. Second, that After= isn't really "after" in the traditional sense, because systemd will start A, not wait for A to be up and running and immediately after the "A has been started"-event start B. If you really want A to be available when B is started (which is the traditional init-script sense of "after") you need to modify the software A to signal completion to systemd or you need some horrible shellscript cludges in the Exec=-line of B that checks for the availability of A. Or an inbetween unit with a Exec=sleep 5 or something. Claiming "it is just 1 line" is either inexperience or dishonesty.
choeger 6y ago
Systemd does a lot of things right: Having one process for the init, declarative definition of common options, streamlined interface. Note that many distros used to provide shell libraries for the same effect, but ended up with incompatible init scripts. In the end, the init script style is just the bare minimum that works solely by POSIX features and is a PITA when it comes to advanced use cases like dependencies or machine-readable system state or platform independent init definitions. Systemd is certainly not the ultimate tool ever written, but it is a bold step in the right direction. Maybe someone will rewrite it someday (if so, presumably in rust) and I will appreciate the effort to make things even better.
Shish2k 6y ago
> This is a lot simpler than migrating to (and getting locked in to) systemd Depends on your perspective - for a developer, “do whatever you want in whatever way you’re comfortable with” is simple. As a sysadmin, I much prefer the simplicity of “there is one way to do it; features like resource limits and automatic restarts work out of the box, and are consistent across all services”.
im3w1l 6y ago
The flexibility for the author makes it harder for the reader though. I can read a systemd service file from top to bottom and understand everything in a minute or two. That's valuable for me.

otabdeveloper4 6y ago

systemd is exactly the boot time interpreter you're asking for.

corty 6y ago
No, systemd doesn't really interpret much, unit files are mostly not a full replacement for what init-scripts were capable of. Which leads to lots of Exec=/some/shell/script.sh in unit files which is worse than before because now you have multiple files and more strange interactions.
- BenjiWiebe 6y ago
  Is that actually common? I write quite a few systemd unit files, and have yet to need a wrapper shell script. And the vast majority, or maybe even all, of the unit files my system has by default are also not calling shell scripts.
  - alerighi 6y ago
    Depends on what you are doing. Init scripts where simpler because the boot process was well defined, meaning that you had all your scripts in rc.d that were executed in that particular order. Now with systemd is more difficult to have something start after something else, you have all the dependencies and if you get them wrong it will not work. Worse, the boot process is no longer deterministic, meaning that 99 times it could work and it could break the 100th time. On the other side, systemd is a necessary evil for a modern desktop system, where you have multiple events that could fire (hotplug, network, power events, etc). But not so sure if it's that necessary for a server or an embedded device.
    - otabdeveloper4 6y ago
      > Now with systemd is more difficult to have something start after something else Not really, it's just one simple line in a unit file. (https://fedoramagazine.org/systemd-unit-dependencies-and-order/ https://fedoramagazine.org/systemd-unit-dependencies-and-ord...)
      - corty 6y ago
        No. First, you usually need both, Want= and After=. Second, that After= isn't really "after" in the traditional sense, because systemd will start A, not wait for A to be up and running and immediately after the "A has been started"-event start B. If you really want A to be available when B is started (which is the traditional init-script sense of "after") you need to modify the software A to signal completion to systemd or you need some horrible shellscript cludges in the Exec=-line of B that checks for the availability of A. Or an inbetween unit with a Exec=sleep 5 or something. Claiming "it is just 1 line" is either inexperience or dishonesty.

choeger 6y ago

Systemd does a lot of things right: Having one process for the init, declarative definition of common options, streamlined interface. Note that many distros used to provide shell libraries for the same effect, but ended up with incompatible init scripts. In the end, the init script style is just the bare minimum that works solely by POSIX features and is a PITA when it comes to advanced use cases like dependencies or machine-readable system state or platform independent init definitions. Systemd is certainly not the ultimate tool ever written, but it is a bold step in the right direction. Maybe someone will rewrite it someday (if so, presumably in rust) and I will appreciate the effort to make things even better.

Shish2k 6y ago

> This is a lot simpler than migrating to (and getting locked in to) systemd Depends on your perspective - for a developer, “do whatever you want in whatever way you’re comfortable with” is simple. As a sysadmin, I much prefer the simplicity of “there is one way to do it; features like resource limits and automatic restarts work out of the box, and are consistent across all services”.

im3w1l 6y ago

The flexibility for the author makes it harder for the reader though. I can read a systemd service file from top to bottom and understand everything in a minute or two. That's valuable for me.