3 ms·

I can't see how that is the case. Why is this any less clear? I don't think following the Fedora debug guide is any less difficult than troubleshooting a SysV-i

I can't see how that is the case. Why is this any less clear? I don't think following the Fedora debug guide is any less difficult than troubleshooting a SysV-init script. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems https://fedoraproject.org/wiki/How_to_debug_Systemd_problems It's curious that he says "Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs." That's not exactly true now, is it? He seems to be implying that there are closed source binaries in the Linux kernel...

chris_wot 11y ago
Funny how nobody can answer this question!
- jack9 11y ago
  You already answered the question and acted like it wasn't an answer: "Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities," - yeah, those binary blobs (inherently unstable blobs of logic). http://linoxide.com/linux-how-to/linux-systemd/ http://linoxide.com/linux-how-to/linux-systemd/
  - chris_wot 11y ago
    There isn't anything "inherently unstable" about them! The only true competitor to systemd is s6, and you should see the amount of "binary" he has had to develop to get his service manager to run outside of PID 1! However... it's all a moot point, because that isn't the definition of a "binary blob". In the context of Linux, or "free and open-source software, a binary blob is a closed-source binary-only piece of software without publicly available source code." [1] 1. https://en.wikipedia.org/wiki/Binary_blob https://en.wikipedia.org/wiki/Binary_blob
chronid 11y 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 11y 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 11y 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 11y ago
      I mentioned dash and ash. I'm aware of the difference across distros.
- chris_wot 11y 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?

chris_wot 11y ago

Funny how nobody can answer this question!

jack9 11y ago
You already answered the question and acted like it wasn't an answer: "Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities," - yeah, those binary blobs (inherently unstable blobs of logic). http://linoxide.com/linux-how-to/linux-systemd/ http://linoxide.com/linux-how-to/linux-systemd/
- chris_wot 11y ago
  There isn't anything "inherently unstable" about them! The only true competitor to systemd is s6, and you should see the amount of "binary" he has had to develop to get his service manager to run outside of PID 1! However... it's all a moot point, because that isn't the definition of a "binary blob". In the context of Linux, or "free and open-source software, a binary blob is a closed-source binary-only piece of software without publicly available source code." [1] 1. https://en.wikipedia.org/wiki/Binary_blob https://en.wikipedia.org/wiki/Binary_blob

chronid 11y 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 11y 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 11y 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 11y ago
    I mentioned dash and ash. I'm aware of the difference across distros.
chris_wot 11y 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?