Re: Journey to s6-svscan as PID 1 on FreeBSD (almost there)

From: Laurent Bercot <>
Date: Thu, 08 Apr 2021 13:52:14 +0000

>Finally I sucked up the courage and defined in /boot/loader.conf
>which contains
>#!/usr/local/bin/execlineb -S0
>redirfd -wnb 1 /m/fifo/catch_all
>redirfd -r - /dev/null
>fdmove -c 2 1
>exec -c /sbin/s6/svscan -t 0 -s /s/scan
>And finally /sbin/s6-svscan runs as pid 1.

  That's awesome! So, if I understand correctly:

  - /sbin/init is still the first program loaded by the kernel, it's
the stock FreeBSD thing that performs FreeBSD-specific setups
  - if there is an init_exec entry in /boot/loader.conf, /sbin/init
execs into its value, which allows you to run a different pid 1
for the lifetime of the machine.

  If that's really how it works, it's incredibly good, and would make
s6-freebsd-init a breeze to write.
  The necessary modifications to turn s6-linux-init into s6-freebsd-init
would just be:

  - Comment out kbspecials() and its invocations:
(does FreeBSD's /sbin/init set up CAD handling and other related
console things?)
  - Port the mount() and umount() invocations, replacing mount with the
correct FreeBSD way of mounting a tmpfs:
  - Port the final reboot() call:

  and all the rest should work as is. It's a game-changer.

>foreground { /sbin/shutdown -o -r now } # this invokes reboot rather
>than send a signal to init.
>I'd greatly appreciate advice as to completing a clean shutdown?

  My current approach is, indeed, to keep s6-svscan running as pid 1,
without making it exec into anything else, for the whole lifetime of
the machine, shutdown procedure included. So yes, for a clean
shutdown, you'd just make sure to kill all processes, then unmount
filesystems (and remount / read-only), then invoke reboot/poweroff
directly. That is how the current s6-linux-init works; I don't see a
reason why it shouldn't work on FreeBSD.

>PS This journey commenced with the simple wish to safely rotate apache
>logs, now I'm hooked on s6-rc (and the peace of mind it brings)

  Glad you like it :)

Received on Thu Apr 08 2021 - 13:52:14 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC