Re: Hello world and couple of questions

From: Jan Bramkamp <crest_at_rlwinm.de>
Date: Tue, 8 Sep 2015 13:31:32 +0200

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.
Received on Tue Sep 08 2015 - 11:31:32 UTC