You don't need to write your own, we already have this git.suckless.org
Thats right, you don't even need 100 lines to have a fully functioning init. In this config.h is your inittab, and rcinitcmd[] is what gets called after the kernel calls sinit (You need init=/bin/sinit or whatever on your kernel cmdline). rcinitcmd[] is an going to be your init script which mounts procfs/sysfs(in the case of linux) and then mounts any other filesystems you want (devfs, any local filesystems). At some point after sysfs/procfs it can bring up your loopback interface, run an fsck, seed /dev/urandom, and at the end can call another script which will spawn your services such as agetty, sshd, or any other daemons you want running.
[devuan] Devuan "ASCII" 2.0 Release Candidate
cool
An init that doesn't initialize like 99% of a modern Linux system and leaves it to what is going to be essentially another init is fucking garbage, user. How do I use cgroups with that? All that shit needs to be in whatever is the parent of everything else so is a natural fit for pid 1.
Why didn't you mention that you wanted something that implements the freedesktop shitware of the week. systemd already does that for, all packaged up into one monstrosity of terrible ideas. But of course my method can also start all that shit. Want udev? Spawn udev instead of mounting devfs. Want dbus? Spawn dbusd. Want tmpfilesd(or whatever the fuck that cancer is)? Launch that in your init scripts
By using cgexec, cgcreate, and friends in your init script. Or alternatively by using the cgroups vfs. Personally I think cgroups are retarded and if linus had just implemented the chroot protections that grsec created (or just fixed his own shitty implementation) then there would be no need for cgroups.
No, all pid 1 has to do is wait for children to reap and spawn an init script.
unix.stackexchange.com
>Dealing with orphaned processes is (with recent Linux kernels, as explained at unix.stackexchange.com