supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Jan Bramkamp <crest@rlwinm.de>
To: Jonathan de Boyne Pollard
	<J.deBoynePollard-newsgroups@NTLWorld.com>,
	Adrian Chadd <adrian@freebsd.org>,
	Supervision <supervision@list.skarnet.org>,
	FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject: Re: Linuxisms in s6
Date: Thu, 25 Aug 2016 11:56:37 +0200	[thread overview]
Message-ID: <ffc52048-67da-a0bb-d24a-275b7578b858@rlwinm.de> (raw)
In-Reply-To: <37d5159b-4957-42f8-2252-fa53d7446bb6@NTLWorld.com>

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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  reply	other threads:[~2016-08-25  9:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25  4:53 Jonathan de Boyne Pollard
2016-08-25  9:56 ` Jan Bramkamp [this message]
2016-08-25 15:46 ` Adrian Chadd
2016-08-25 19:48   ` Lars Engels
2016-08-25 21:08     ` Adrian Chadd
2016-08-25 21:13       ` Warner Losh
2016-08-25 21:17         ` Adrian Chadd
2016-08-26 10:44           ` Jan Bramkamp
2016-08-26 14:11             ` Warner Losh
2016-08-27 16:37       ` Jonathan de Boyne Pollard
2016-08-28  1:58         ` Adrian Chadd
2016-08-27 13:38   ` Jonathan de Boyne Pollard
2016-08-27 16:51   ` Jonathan de Boyne Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffc52048-67da-a0bb-d24a-275b7578b858@rlwinm.de \
    --to=crest@rlwinm.de \
    --cc=J.deBoynePollard-newsgroups@NTLWorld.com \
    --cc=adrian@freebsd.org \
    --cc=freebsd-hackers@freebsd.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).