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.
