> On Thu, 8 Dec 2016 08:33:22 +0000
> Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com> wrote:
>
> Martin "eto" Misuth:
> > On my presonal box "user level" s6 /services subtrees are in
> > `.config/s6/host`
>
> For comparison: ~/.config/service-bundles/services/ and
> ~/.config/service-bundles/targets/
Well what I like most is that I am in control, and I decide trees locations,
yet I can easily "merge trees" with system level supervisors.
Not just that, I can assemble "application subtrees" as well, that themselves
are "supervisable".
Most importantly when paired with some scripting language, I can actually make
things that run on both systemdized linux machines, non systemdized linux
ones and on several other OSes.
> On Thu, 8 Dec 2016 08:33:22 +0000
> Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com> wrote:
>
> Martin "eto" Misuth:
> > #!/bin/sh
> > exec mpd --no-daemon /usr/home/eto/.config/mpd/mpd.conf
>
> Tip: In the daemontools world all services have ther own service
> directory, at minimum; and this directory is the working directory of
> the service. You can put an mpd.conf that is particular to the service
> in the service directory itself.
>
> On Thu, 08 Dec 2016 09:55:11 +0000
> "Laurent Bercot" <ska-supervision_at_skarnet.org> wrote:
> Additionally, most Unix distributions traditionally keep their config
> files in /etc, and the change to a supervision system is already a big
> shock to them - the shock can be made easier to overcome if we don't
> change all the habits at once. :)
>
> Anyway, I don't think we should be arguing one way or the other;
> policy decisions are best left to sysadmins and distributions.
I use <servicedir> with my own scripts, but for things having
local /etc, /usr/local/etc alternatives I prefer those.
>
> Martin "eto" Misuth:
> > Getting tmux "supervised" was bit tricky as it double forks the daemon
> > if not running, and is thus is "escaping under init" under normal
> > conditions.
>
> Note: This can be easily handled on FreeBSD and TrueOS. See NOTE_TRACK
> in EVFILT_PROC for kevent().
I saw that filter, and tried to find examples, but my google-fu is not that good
these days of dumbed down search engines. The sad thing is that it is kqueue
only. Although kqueue is wonderful, it's BSDs only :). And although I would love
to have only BSDs on servers, I still have to have "exit path" into linux world.
But still kqueue is very nice indeed.
With other person on irc, we noticed there are some gotchas to subreaping,
especially reparented zombies don't sometimes (never?) generate SIGCHLD.
I think that might be the reason why my PID1 s6-svscan on FreeBSD is
accumulating zombies sometimes (seems like it is affected by dead descendants of
ssh and my experiments).
More over although procctl() on BSDs allows one to enumerate whole subreaper
tree and even send signals atomically, it's not that ideal.
"No children" case detection with "nonblocking wait'n'see ECHILD" seems pretty
sufficient to me, at least for that for that one case. But i belive smething
better could be done.
Anyway as you are probably much closer to FreeBSD team than I am, what do
you think are chances of subreaping capable BSDs to gain new kqueue note
NOTE_REPARENTED in EVFILT_PROC filter?
This would allow one to simply "sleep" indefinitely in core of event loop until
reparented process is acquired as child, and add it to "wait_for" list for example.
Currently, I am noticing, that if I want to be 100% sure, that I "eat" also
reparented zombies, I need to wake up periodically.
> Martin "eto" Misuth:
> > It would be great if tmux project allowed to spawn raw user level
> > daemon by explicit command,
>
> One of the interesting developments over the past couple of decades is
> how much the world has been influenced to come around to the daemontools
> way of doing this. I've observed before, elsewhere, the number of
> daemon programs, especially in the BSD worlds, that have in that time
> gained -F/--foreground or similar options that tell them not to do a
> whole bunch of this unnecessary stuff.
I think this is bit related to daemon(8) program which acts as poor man's runsv,
with all the "advandages" of pid files.
> It's in a way somewhat saddening to see the new option to emacs that
> started this thread. It's welcome; but the sad part is that it's a
> decade and a half behind quite a lot of others. For some systems like
> emacs the process has been glacially slow. MySQL is another.
> daemontools users were asking about letting daemontools do the service
> management and doing away with mysqld_safe in 2002. It took thirteen
> years for it to happen ... in MariaDB. Oracle, where software goes to
> die, may or may not have done the same for MySQL. PostgreSQL lags
> further behind.
I am not so sure about PostgreSQL my experience differs a bit:
"By default postgres starts in the foreground and prints log messages to the
standard error stream." [1]
But what do I know.
[1]
https://www.postgresql.org/docs/9.6/static/app-postgres.html
Received on Thu Dec 08 2016 - 12:28:42 UTC