3 ms·

You seem to forget that the bash scripts are the entire rc system. In systemd, the init binary and utilities are the entire rc system. Those commands will not

by chronid 10y ago

You seem to forget that the bash scripts are the entire rc system. In systemd, the init binary and utilities are the entire rc system. Those commands will not help you if you have to find a bug into systemd code to find something like a constant on the maximum size of a core dump and work around it. Then open a bug and hope it does not get ignored for ~3 years. But who needs core dumps anyway, right?

SwellJoe 10y ago
What happens when there's a bug in bash? Same thing. init is not the only component or source of complexity in the old way. Sometimes the problem will be in the script, sometimes it'll be in the thing that runs the script. Initscripts are vastly more complex than systemd service definition files (and the latter is declarative rather than procedural). Systemd pushes some of the complexity down the stack, and that is a reasonable choice. There will be more bugs in systemd than init and bash (or ash or dash), simply based on age and maturity of the respective projects. There's complaints to be made about systemd, but I don't find this complaint compelling, at all. I think moving from procedural programs that are sometimes hundreds of lines long to declarative config files that are never more than a couple dozen is an overwhelmingly positive thing.
- stephenr 10y ago
  To both of you: s/bash/shell/ On Debian they're specifically not bash scripts, they're posix shell scripts and /bin/sh is provided by dash which is much lighter than bash. I like the declarative nature of service files I'm just not a fan of the hoops it makes us jump through to achieve the same results (see my other comment about changing daemon args)
  - SwellJoe 10y ago
    I mentioned dash and ash. I'm aware of the difference across distros.
chris_wot 10y ago
The bash scripts invoke programs and wrapper programs. It's a bit ridiculous to say that she'll scripting is the only thing that operates startup of services in a system. It's not like new services and startup programs aren't constantly being introduced - so whilst the old scripts were pretty steady, new ones weren't always foolproof. I'm not adverse to SysV and rc scripts, but they were never the panacea that some grey-beards make out. Dependency orders and parallelisation are particularly difficult, but it could be argued the scripts give control during the boot process. I think in practice, it's fairly rate that the scripts were really needed - certainly systemd's more declarative nature for a problem that naturally lends itself to a dependency structure that has a directed acyclic graph seems like it's quite an effective an elegant approach! Aside from the reasonable daemon-arguments issue you raise in the other comment (I just read this, interesting observation!) I really feel that systemd largely eliminates huge quantities of shell scripting in the startup process! I've been wondering what scenarios there are that would require scripting. I thought that perhaps a more complex setup might be that a service needs to wait on two or three processes before starting, in which case a child can have multiple parents? Can systemd handle that?

by chronid 10y ago

SwellJoe 10y ago

What happens when there's a bug in bash? Same thing. init is not the only component or source of complexity in the old way. Sometimes the problem will be in the script, sometimes it'll be in the thing that runs the script. Initscripts are vastly more complex than systemd service definition files (and the latter is declarative rather than procedural). Systemd pushes some of the complexity down the stack, and that is a reasonable choice. There will be more bugs in systemd than init and bash (or ash or dash), simply based on age and maturity of the respective projects. There's complaints to be made about systemd, but I don't find this complaint compelling, at all. I think moving from procedural programs that are sometimes hundreds of lines long to declarative config files that are never more than a couple dozen is an overwhelmingly positive thing.

stephenr 10y ago
To both of you: s/bash/shell/ On Debian they're specifically not bash scripts, they're posix shell scripts and /bin/sh is provided by dash which is much lighter than bash. I like the declarative nature of service files I'm just not a fan of the hoops it makes us jump through to achieve the same results (see my other comment about changing daemon args)
- SwellJoe 10y ago
  I mentioned dash and ash. I'm aware of the difference across distros.

chris_wot 10y ago

The bash scripts invoke programs and wrapper programs. It's a bit ridiculous to say that she'll scripting is the only thing that operates startup of services in a system. It's not like new services and startup programs aren't constantly being introduced - so whilst the old scripts were pretty steady, new ones weren't always foolproof. I'm not adverse to SysV and rc scripts, but they were never the panacea that some grey-beards make out. Dependency orders and parallelisation are particularly difficult, but it could be argued the scripts give control during the boot process. I think in practice, it's fairly rate that the scripts were really needed - certainly systemd's more declarative nature for a problem that naturally lends itself to a dependency structure that has a directed acyclic graph seems like it's quite an effective an elegant approach! Aside from the reasonable daemon-arguments issue you raise in the other comment (I just read this, interesting observation!) I really feel that systemd largely eliminates huge quantities of shell scripting in the startup process! I've been wondering what scenarios there are that would require scripting. I thought that perhaps a more complex setup might be that a service needs to wait on two or three processes before starting, in which case a child can have multiple parents? Can systemd handle that?