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

From: Dewayne Geraghty <dewayne.geraghty_at_heuristicsystems.com.au>
Date: Fri, 9 Apr 2021 14:54:57 +1000

On 8/04/2021 11:52 pm, Laurent Bercot wrote:
>> Finally I sucked up the courage and defined in /boot/loader.conf
>> init_exec=/root/bin/init_exec.sh
>> 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.

Yes. That is correct.
Sequence: bios -> boot (MBR & GPT differ slightly) -> loader -> kernel
-> /sbin/init

(loader reads and executes /boot/loader.conf this enables things like
setting kernel environment variables, read-only kernel settings,
attaching encrypted devices, some controls over init and human
interaction with loader. My apologies if its obvious that I have no
knowledge of Linux, as I went from IBM OS, CP/M, VMS, FreeBSD)

>
>  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:
> https://github.com/skarnet/s6-linux-init/blob/master/src/init/s6-linux-init.c#L70
>

I really appreciate the direct links. I'd need to set aside time to
understand what s6-linux-init does, though kbspecials looks like its
performs an open console (been more than 30+ years since I worked in C)

> (does FreeBSD's /sbin/init set up CAD handling and other related
> console things?)

Yes. /sbin/init normally owns the console and runs getty (stuff).
So from init.c
init_exec invokes replace_init(path) -> execute_script() ->
open_console() & execv()
while
init_script -> run_script -> forks -> execute_script -> open_console & execv

>  - Port the mount() and umount() invocations, replacing mount with the
> correct FreeBSD way of mounting a tmpfs:
> https://github.com/skarnet/s6-linux-init/blob/master/src/init/s6-linux-init.c#L209>

init.c creates and calls "mount_tmpfs" (using nmount) which should be a
cut/paste to mount at S6_LINUX_INIT_TMPFS, the purpose for it in FreeBSD
is to enable a reroot to occur :)

I notice runlevels which FreeBSD doesn't have. I don't think the 5
security modes is the same -1 is default, insecure.

>  - Port the final reboot() call:
> https://github.com/skarnet/s6-linux-init/blob/master/src/shutdown/s6-linux-init-hpr.c#L81
>
Yes, I think this is the challenge. I need to figure out why the signals
aren't getting caught (& handled) by s6-svscan. :-/

init.c is 2043 lines of code and a lot of that is in managing ttys and
shutdown. The reboot command should be fairly straight-forward.

Humorous comment re glibc multilib.

>>  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.
>

This is where I'm stuck. If I can achieve a clean shutdown, then init
is a non-issue. Largely because my servers are headless, so I don't
need a console (or ttys) unless I have a hardware fault, in which case
I'd boot from a clean device (if possible).

I've given some thought to modify s6-svscan to include the shutdown
code, but we're not desperate yet.

>
>> 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 :)
>
> --
>  Laurent

Thank-you for your informative reply. I'll schedule some time to work
through this properly and come back.
Received on Fri Apr 09 2021 - 04:54:57 UTC

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