Linuxisms in s6

Jan Bramkamp crest at rlwinm.de
Thu Aug 25 09:56:41 UTC 2016


On 25/08/16 06:53, Jonathan de Boyne Pollard wrote:
> http://adrianchadd.blogspot.co.uk/2016/08/freebsd-on-tiny-system-whats-missing.html?showComment=1471236502051#c1305086913155850955
> , Adrian Chadd:
>
>> We're using s6 at work, and it works out mostly ok. Mostly once you
>> get around the linuxisms, and the lack of sensible time code in it
>> (its calculations for daemon run duration is based on system time, not
>> wall clock, so if your box boots jan 1, 1970 then gets NTP, things
>> are.. hilarious), and some of the arcane bits to get logging working
>> right.
>>
> What are these Linuxisms in s6?  s6-linux-utils and s6-linux-init have
> Linuxisms, obviously.  But what Linuxisms does s6 have?
>

The skalibs library used by s6 to calculate the deadlines should use 
clock_gettime(CLOCK_MONOTONIC) on FreeBSD and as such shouldn't be 
affected by changes to the wall clock.

I'm currently working on a FreeBSD only potential init replacement as 
well just without the mandatory per service supervisor process. The new 
kqueue EVFILT_PROCDESC filter type in FreeBSD 11 combined with pdfork() 
should make it really easy to deal child processes in a single unified 
kevent loop. Forking services could still be handled by a supervisor 
using procctl(PROC_REAP_ACQUIRE).

At the moment I'm fighting with some corner cases in the file descriptor 
passing code and redesigning the API to work without access to a 
writable file system. My last API required a writable file system 
because FreeBSD doesn't support listen()ing on unbound unix domain 
seqpacket sockets and I don't want to require something like the Linux 
/run tmpfs. Instead my new API uses socketpair() to create a connected 
pair of anonymous unix domain sockets for each supervised process. Next 
I have to find out if fexecve() works at least for fd 0, 1 and 2 without 
a mounted fdescfs.

I want to implement the following features in a single process capable 
of running as PID 1:
- Track service dependencies (want, require, bind, conflict)
- Store, Retrieve and close file descriptors.
- Spawn and supervise processes in a well defined environment.
- Reliable event notification with coalescing.
- Bootstrap the system with help from a default service.

With those features it should be able to wrap existing rc.d scripts 
without resorting to polling.


More information about the freebsd-hackers mailing list