5 ms·

That's a fair point, but where is the line? Do sysadmins worry about debugging Linux? Should it be written in Bash so that they can (obviously the kernel can't

That's a fair point, but where is the line? Do sysadmins worry about debugging Linux? Should it be written in Bash so that they can (obviously the kernel can't be written in Bash, but for the sake of argument)? As a non-sysadmin, I just feel like it's totally fair to have PID 1 be about as trusted and uniform as the kernel. If there's a bug in systemd, that's bad. If there's a bug in Linux, that's bad. But can't we at least aim for an init that is not just a bunch of Bash scripts running as root?

drran 6y ago
I have more trust in bash than in C. I can enable tracing in bash script and then see how it executed exactly. IMHO, we should aim for an open standard for the init subsystem instead. For example, I want to implement my init system in Rust, but systemd is blob, which is hard to replace.
- ragnese 6y ago
  > I have more trust in bash than in C. I can enable tracing in bash script and then see how it executed exactly. If I had to work in either day-to-day, I'd chew my hands off. :p > IMHO, we should aim for an open standard for the init subsystem instead. For example, I want to implement my init system in Rust, but systemd is blob, which is hard to replace. Well, hold on. The person I replied to was talking about being able to debug systemd. So this is very tangential to that. If we had an standard for inits, with different implementations, it would be hard to debug all of the ones that are compiled binaries. My point is still that a sysadmin should not be expected to debug PID 1 any more than they should be expected to debug a driver. Also, you can just treat systemd's APIs as the standard. GNOME, for example, depends on launchd. And, IIRC, there was some shim created so that GNOME could run on a BSD, which obviously doesn't have systemd. So, go ahead and write your init in Rust- Rust has great C API/ABI compatibility!
  - drran 6y ago
    Minimal initd is very short: https://github.com/mesalock-linux/minit/blob/master/src/main.rs https://github.com/mesalock-linux/minit/blob/master/src/main... http://git.suckless.org/sinit/file/sinit.c.html http://git.suckless.org/sinit/file/sinit.c.html However, systemd is huge: 1.3 million lines of code. https://www.theregister.com/2020/01/06/linux_2020_kernel_systemd_code/ https://www.theregister.com/2020/01/06/linux_2020_kernel_sys...
    - ragnese 6y ago
      But those inits don't actually DO hardly anything. The Rust one hardcodes a bunch of stuff and has "TODO - setup signal handler" in the code... You're not even comparing them to just the init part of systemd, but the entire repository. What's the point here?
      - drran 6y ago
        The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a daemon must collect their souls). It's not a job of init daemon to manage containers or resolve DNS names. IMHO, systemd must be PID 2+, not PID 1.
        rcxdude 6y ago
        > The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a daemon must collect their souls). Well, those initds don't actually start processes, they start one other process. > It's not a job of init daemon to manage containers or resolve DNS names. systemd's init doesn't do these things, other parts of systemd do that. > IMHO, systemd must be PID 2+, not PID 1. It is, for the most part (certainly most of those '1 million lines of code' are not in PID 1). Certainly you could try to keep more of the service management code out of PID 1, but it's honestly not something with huge practical benefits (your service management is going to be priviledged anyway, in the event of a crash all a non-PID 1 solution allows is maybe a little bit of an easier time giving a chance to inspect the wreckage before you need to restart everything anyway), and you create more interfaces in your system to manage.

drran 6y ago

I have more trust in bash than in C. I can enable tracing in bash script and then see how it executed exactly. IMHO, we should aim for an open standard for the init subsystem instead. For example, I want to implement my init system in Rust, but systemd is blob, which is hard to replace.

ragnese 6y ago
> I have more trust in bash than in C. I can enable tracing in bash script and then see how it executed exactly. If I had to work in either day-to-day, I'd chew my hands off. :p > IMHO, we should aim for an open standard for the init subsystem instead. For example, I want to implement my init system in Rust, but systemd is blob, which is hard to replace. Well, hold on. The person I replied to was talking about being able to debug systemd. So this is very tangential to that. If we had an standard for inits, with different implementations, it would be hard to debug all of the ones that are compiled binaries. My point is still that a sysadmin should not be expected to debug PID 1 any more than they should be expected to debug a driver. Also, you can just treat systemd's APIs as the standard. GNOME, for example, depends on launchd. And, IIRC, there was some shim created so that GNOME could run on a BSD, which obviously doesn't have systemd. So, go ahead and write your init in Rust- Rust has great C API/ABI compatibility!
- drran 6y ago
  Minimal initd is very short: https://github.com/mesalock-linux/minit/blob/master/src/main.rs https://github.com/mesalock-linux/minit/blob/master/src/main... http://git.suckless.org/sinit/file/sinit.c.html http://git.suckless.org/sinit/file/sinit.c.html However, systemd is huge: 1.3 million lines of code. https://www.theregister.com/2020/01/06/linux_2020_kernel_systemd_code/ https://www.theregister.com/2020/01/06/linux_2020_kernel_sys...
  - ragnese 6y ago
    But those inits don't actually DO hardly anything. The Rust one hardcodes a bunch of stuff and has "TODO - setup signal handler" in the code... You're not even comparing them to just the init part of systemd, but the entire repository. What's the point here?
    - drran 6y ago
      The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a daemon must collect their souls). It's not a job of init daemon to manage containers or resolve DNS names. IMHO, systemd must be PID 2+, not PID 1.
      - rcxdude 6y ago
        > The initd job IS to launch other processes and reap zombies. (To non-technical people: zombies are childs which died when their parent is already dead, so a daemon must collect their souls). Well, those initds don't actually start processes, they start one other process. > It's not a job of init daemon to manage containers or resolve DNS names. systemd's init doesn't do these things, other parts of systemd do that. > IMHO, systemd must be PID 2+, not PID 1. It is, for the most part (certainly most of those '1 million lines of code' are not in PID 1). Certainly you could try to keep more of the service management code out of PID 1, but it's honestly not something with huge practical benefits (your service management is going to be priviledged anyway, in the event of a crash all a non-PID 1 solution allows is maybe a little bit of an easier time giving a chance to inspect the wreckage before you need to restart everything anyway), and you create more interfaces in your system to manage.