On 07/09/15 16:36, Martin "eto" Misuth wrote:
Hi, new s6 user here. I started using s6 to do FreeBSD jail services management. It seems this helped me to get rid of some socket timeout errors (?) in my jails setups. In my deployment I am using "jail as vm" approach. This works pretty well in my testing vm and on testing server. Being very happy with the preliminary system I decided I want to replace init on freebsd similar way runit does it. However runit is fullblown init in stage 1 + and zombie reaper in stage 2, while s6 uses execline script for stage 1. After some smashing things together, I took original init.c from base FreeBSD src tree and removed parts until it's just rudimentary initialization function that execves into execlineb boot script. My environment is ZFS only so, I just did really dirty hacks to have ZFS fses, and some other late fses mounted and some other things. This seems to work reliably both in vm and on real hw.
I too ran into the problem of incompatible signal number conventions between FreeBSD and Linux init processes. My solution was to #ifdef the signal handler registration in the s6 init code and write a few ports which install the skatools collection in base (PREFIX=/ instead of the normal PREFIX=/usr/local). These ports install all the binaries in /bin and /sbin and because they need only the libc at runtime execline scripts work as early init. As init has to mount all filesystems except / it has to work with just the contents of the root fs. By convention ports install as much as possible under a $PREFIX of /usr/local. Unless you want to mix /package with hier(7) a proper execline port usable as early init "interpreter" would require the port to install into the rootfs which means /bin (and interpreter has no place in /sbin). Since most of the s6 suite is required for debugging any problems the s6 port should install its binaries into the rootfs as well. This rest of the nice s6 tools. They probably should install into /usr/local like normal ports and the services, because the early init script should mount all the critical (local) filesystems or fail hard.
One problem I am having though, is "uncaught" logger dance, as unlike on linux, stage 1 dies with "broken pipe" signal when it tries to write to logger fifo (as it has no reader yet). For now I got around that by redirecting stderr to logger only right before supervisor boots up, however that means initial messages appear only on console.
Setting up a default logger requires some trickery. The idea is to open a non-blocking pipe (because opening a blocking pipe requires a reader) and toggle the opend pipe from non-blocking to blocking.
Is there some way to buffer those from fifo until last resort logger starts (using tools in s6 packages)? Or can I somehow spawn logger before supervisor spins up and have it "descent" later into supervision tree?
I have a working FreeBSD default logger service and early init execline script in a virtualbox VM.
Second problem is when I compile s6 and portable utils package with: ./configure --enable-static-libc all s6 tools are correctly identified by 'file' command as fully static ELFs, however s6-svstat for example fails to work correctly.
There is no reason the use a static libc on FreeBSD unless you plan to break your linker or libc. In all my years I never needed /rescue because my linker was broken.
It always reports given service as down. Without static libc it all works as intended. Is this a bug?
As a user I would consider this a bug. The question is if it's a bug in the FreeBSD libc or s6-svstat. But there are few good reasons to link static binaries on FreeBSD and quiet a few reasons against static linking among them that updates to the FreeBSD world may patch the libc without rebuilding your static binaries.
