0

So typically an initramfs /init script will end with something like

exec switch_root /newroot /sbin/init

effectively replacing itself with systemd or whatever floats your boat. But what would happen if you fork prior to this? Will the new init system still be the parent of the forked process or will it be a zombie? In case of systemd, will a child process created before systemd starts create "bookkeeping problems" or have other unforeseen side effects?

Edit: Was asked in a comment for example code. Can't really see how that would change the principles behind the answer, but sure:

tail -f /dev/urandom &
exec switch_root /newroot /sbin/init
  • can you show us the proposed code? – ctrl-alt-delor Jun 25 '18 at 17:29
2

The answer is that nothing much happens. You're replacing your process by execing - the forked process only knows that its parents pid is 1, it doesn't really care if that process was systemd or some initramfs /init. The only shady bit is that it will be a daemon without a systemd service so journalctling, restarting, etc. won't work right -- unless you specifically brew your own service that "attaches" itself to the forked process (probably not very hard given that it should have a deterministic pid etc).

It is generally not encouraged to have left-over initramfs code running after regular boot for exactly these reasons, but it won't crash your system. There's some interesting discussion in the comment fields of https://lwn.net/Articles/657345/ where this is discussed briefly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.