4 ms·

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IM

by CSDude 10y ago

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

geofft 10y ago
1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code. 2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing?? And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility. 3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?
- chris_wot 10y ago
  For point 2, I think you can use: ps -eLf | grep '\[' I put in a grep root for good measure: ps -eLf | grep '\[' | grep root Incidentally, why would a zombie process need to be reparented? Surely it has just not been removed from the process table and all that needs to occur is to remove it fully... I can understand reparenting an orphan process, but a zombie process?
  - geofft 10y ago
    A ps roughly like that is how I got the number. That doesn't explain what they do. I'm sure I could dig into kernel sources, but... for instance, why am I running "xfsalloc", "xfs_mru_cache", and "xfslogd" when I have no XFS file systems? The point I'm making is not so much that I'm curious (although I am), but that the kernel is exempt from the scrutiny that systemd gets, and the kernel has a ton of fragile crap running at full privilege. If systemd even shipped three XFS-specific binaries, people would be upset, but the kernel can run three persistent kernel threads and nobody cares.
    - chris_wot 10y ago
      You either have the xfs filesystem module loaded or compiled into your kernel. I just tested this out: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$ sudo modprobe xfs [sudo] password for chris: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs root 6731 2 6731 0 1 16:53 ? 00:00:00 [xfsalloc] root 6736 2 6736 0 1 16:53 ? 00:00:00 [xfs_mru_cache] chris@libreoffice-ia64:~$ chris@libreoffice-ia64:~$ sudo rmmod xfs chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$
      - geofft 10y ago
        I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko. My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general, about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are contributing to the existing efforts already in Debian to officially support alternative kernels.)
        chris_wot 10y ago
        Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.
        digi_owl 10y ago
        The kernel also lives in kernel space, so unless one go micro-kernel, and dumps everything but the bare minimum into user space, a kernel will always be a big blob of code (most of it drivers, btw).
witty_username 10y ago
> functionality That is, actually doing the work of init i.e. spawning daemons and services.
- marcosdumay 10y ago
  Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts. It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.
  - chris_wot 10y ago
    Sure it does. Letting systemd handle startup dependencies is a very good thing, IMO. You configure some unit files to allow for one unit to start after another, otherwise they run in parallel. Not sure what the issue is with that? As for those other tools... well, the systemd init process doesn't manage those either. The anciliary modules do, and quite well too really. I'm not entirely sure why people think that this is much different to running a SysV script to execute start a daemon!
JdeBP 10y ago
Ahem! * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132
- chris_wot 10y ago
  Those StackExchange answers are awesome.

by CSDude 10y ago

geofft 10y ago

1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code. 2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing?? And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility. 3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?

chris_wot 10y ago
For point 2, I think you can use: ps -eLf | grep '\[' I put in a grep root for good measure: ps -eLf | grep '\[' | grep root Incidentally, why would a zombie process need to be reparented? Surely it has just not been removed from the process table and all that needs to occur is to remove it fully... I can understand reparenting an orphan process, but a zombie process?
- geofft 10y ago
  A ps roughly like that is how I got the number. That doesn't explain what they do. I'm sure I could dig into kernel sources, but... for instance, why am I running "xfsalloc", "xfs_mru_cache", and "xfslogd" when I have no XFS file systems? The point I'm making is not so much that I'm curious (although I am), but that the kernel is exempt from the scrutiny that systemd gets, and the kernel has a ton of fragile crap running at full privilege. If systemd even shipped three XFS-specific binaries, people would be upset, but the kernel can run three persistent kernel threads and nobody cares.
  - chris_wot 10y ago
    You either have the xfs filesystem module loaded or compiled into your kernel. I just tested this out: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$ sudo modprobe xfs [sudo] password for chris: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs root 6731 2 6731 0 1 16:53 ? 00:00:00 [xfsalloc] root 6736 2 6736 0 1 16:53 ? 00:00:00 [xfs_mru_cache] chris@libreoffice-ia64:~$ chris@libreoffice-ia64:~$ sudo rmmod xfs chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$
    - geofft 10y ago
      I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko. My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general, about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are contributing to the existing efforts already in Debian to officially support alternative kernels.)
      - chris_wot 10y ago
        Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.
        digi_owl 10y ago
        The kernel also lives in kernel space, so unless one go micro-kernel, and dumps everything but the bare minimum into user space, a kernel will always be a big blob of code (most of it drivers, btw).

witty_username 10y ago

> functionality That is, actually doing the work of init i.e. spawning daemons and services.

marcosdumay 10y ago
Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts. It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.
- chris_wot 10y ago
  Sure it does. Letting systemd handle startup dependencies is a very good thing, IMO. You configure some unit files to allow for one unit to start after another, otherwise they run in parallel. Not sure what the issue is with that? As for those other tools... well, the systemd init process doesn't manage those either. The anciliary modules do, and quite well too really. I'm not entirely sure why people think that this is much different to running a SysV script to execute start a daemon!

JdeBP 10y ago

Ahem! * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132

chris_wot 10y ago
Those StackExchange answers are awesome.