supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Guillermo <gdiazhartusch@gmail.com>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: The "Unix Philosophy 2020" document
Date: Sat, 28 Dec 2019 15:05:59 -0300	[thread overview]
Message-ID: <CADQ2Nw_8uUjeaM0y1ySa=9pgT1teefcvR-+p8HjK9xcrT0Jr7Q@mail.gmail.com> (raw)
In-Reply-To: <20191228140453.GB198054@cube>

El sáb., 28 dic. 2019 a las 11:06, Alex Suykov escribió:
>
> Minor note on this. Resource limiting with cgroups does not require
> any explicit support from s6, or any external tools for that matter.
> Literally just `echo $$ > $cg/cgroup.procs` in the startup script
> is enough, assuming the group has been created (mkdir) and the limits
> have been set (bunch of echo's).

Exactly. And that's what nosh's move-to-control-group(1) and
set-control-group-knob(1) do. They are convenience tools invoked by
nosh scripts generated by conversion of unit files (with
'system-control convert-systemd-units'). Nosh's service manager
doesn't directly deal with cgroups, and neither does its PID 1
program.

> The whole thing regarding cgroups in systemd is really about a very
> different problem: supervising broken services that exit early and
> leave orphaned children behind.

I'm not sure if it is specifically for that. AFAIK, it is an
implementation detail of 'KillMode=control-group' and 'KillMode=mixed'
unit file directives. Daemons that use those, like GDM, seemingly
'stay in the foreground', and can therefore be supervised, but spawn
child processes (and/or threads?) that they expect someone else to
kill when they exit.

* https://www.freedesktop.org/software/systemd/man/systemd.kill.html#KillMode=
* https://gitlab.gnome.org/GNOME/gdm/blob/3.34.1/data/gdm.service.in

(A BusName directive and no Type directive means, I think, that the
process can be supervised, and should be considered ready when it
acquires a bus name)

For those cases, I believe only the "read PIDs from cgroup.procs and
kill corresponding processes until no more PIDs are read" part of the
'babysitter' functionality is needed, and IMO that fits better in the
finish file, like in Oliver's example.

As for the "Is there real pressure to have this?" question, I guess it
depends on how many daemons that need o rely on this KillMode
functionality actually exist? Do we know?

G.


  reply	other threads:[~2019-12-28 18:05 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190831130730.ki6ma7i5curucowe@caspervector>
     [not found] ` <em5af31b6f-4dd3-4a31-a6cf-beccb100238d@elzian>
     [not found]   ` <20190901091157.bjtfhqq6d2rg75yo@CasperVector>
2019-09-27  8:38     ` Casper Ti. Vector
2019-10-12 17:37       ` Casper Ti. Vector
2019-10-12 18:58         ` Steve Litt
2019-10-12 19:14           ` Casper Ti. Vector
2019-10-13  3:31         ` Casper Ti. Vector
2019-10-13  8:21         ` Oliver Schad
2019-10-13 13:57           ` Casper Ti. Vector
2019-12-08 17:04             ` Casper Ti. Vector
2019-10-14  6:35           ` Jens Rehsack
2019-10-22 15:33         ` Casper Ti. Vector
2019-10-22 16:54           ` Steve Litt
2019-10-22 17:07             ` Casper Ti. Vector
2019-11-17  6:26         ` Casper Ti. Vector
2019-11-17  7:28           ` Casper Ti. Vector
2019-11-24 20:13             ` Guillermo
     [not found]               ` <20191125025202.oqu4ennu3lexnxsa@caspervector>
2019-11-25  2:52               ` Casper Ti. Vector
2019-11-25 14:20                 ` Casper Ti. Vector
2019-11-30 12:13                   ` Jeff
2019-11-30 12:20                     ` Jeff
2019-11-30 12:45                       ` Jeff
2019-11-30 13:29                         ` Laurent Bercot
2019-11-30 14:43                           ` Casper Ti. Vector
2019-11-30 15:01                             ` Jeff
2019-11-30 15:48                               ` Casper Ti. Vector
2019-11-30 16:58                                 ` Jeff
2019-12-26 17:52           ` Casper Ti. Vector
2019-12-27  1:09             ` Oliver Schad
2019-12-27 11:11               ` Casper Ti. Vector
2019-12-27  2:57             ` Steve Litt
2019-12-27 13:54               ` Casper Ti. Vector
2019-12-27 15:37                 ` Casper Ti. Vector
2020-01-04  9:10                   ` Casper Ti. Vector
2020-01-04 18:25                     ` fungal-net
2020-01-05  0:36                       ` Casper Ti. Vector
2020-01-05  6:31                       ` Casper Ti. Vector
2020-01-05  6:54                         ` Casper Ti. Vector
2019-12-27 23:05                 ` Steve Litt
     [not found]               ` <20191227135411.jbtxorloetcvv5bx@caspervector>
     [not found]                 ` <20191227153719.2tt4bbidp3v7t23u@caspervector>
     [not found]                   ` <20200104091013.wesvxvcqxquc5n2h@caspervector>
2020-01-04 12:32                     ` Laurent Bercot
2019-12-27 21:29             ` Steve Litt
2019-12-27 23:34               ` Alex Suykov
2019-12-28 10:35               ` Casper Ti. Vector
2019-10-28 15:34       ` Avery Payne
2019-10-28 15:51         ` Casper Ti. Vector
     [not found]   ` <20190901091157.bjtfhqq6d2rg75yo@caspervector>
     [not found]     ` <20190927083816.tectynx7dzlfcvb7@caspervector>
     [not found]       ` <20191012173743.drzlgnrw4hib6hh4@caspervector>
     [not found]         ` <20191117062644.lt6wfmqwijqqhc5w@caspervector>
     [not found]           ` <20191226175258.o2nsregew6tlqlbu@caspervector>
2019-12-26 19:17             ` Laurent Bercot
2019-12-27 11:23               ` Casper Ti. Vector
2019-12-28  2:24                 ` Alex Suykov
2019-12-28  2:57                   ` eric vidal
2019-12-28 14:04                     ` Alex Suykov
2019-12-28 18:05                       ` Guillermo [this message]
2019-12-28 23:19                         ` Oliver Schad
2019-12-28 18:12                       ` Oliver Schad
2019-12-28 21:32                       ` eric vidal
2019-12-28  6:46                   ` Steve Litt
2019-12-28 13:37                     ` Alex Suykov
2019-12-28 13:54                       ` Casper Ti. Vector
2019-12-28 17:41                       ` Oliver Schad
2019-12-28 18:29                         ` Serge E. Hallyn
2019-12-28 23:16                           ` Oliver Schad
2019-12-28 21:31                         ` eric vidal
2019-12-29 16:07                         ` Alex Suykov
2019-12-29 20:32                           ` Oliver Schad
2019-12-28 10:26                   ` Casper Ti. Vector
     [not found]               ` <20191227112309.3fow6vynss2ifw4t@caspervector>
2019-12-27 12:32                 ` Laurent Bercot
2019-12-27 13:48                   ` Casper Ti. Vector
2019-12-27 23:54                   ` Oliver Schad
2019-12-27 23:56                     ` Oliver Schad
2019-12-28 15:19                       ` Guillermo
2019-12-28 18:16                         ` Oliver Schad
2019-12-28 20:44                   ` Laurent Bercot

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='CADQ2Nw_8uUjeaM0y1ySa=9pgT1teefcvR-+p8HjK9xcrT0Jr7Q@mail.gmail.com' \
    --to=gdiazhartusch@gmail.com \
    --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).