On 14/07/2015 18:23, Colin Booth wrote:
> And s6-rc shouldn't be responsible for handling the creation and
> mounting of its tmpfs, system specific or not. That's the
> responsibility of the system administrator or the package maintainer.
Obviously.
> s6-rc-db: [-d] dependencies servicename exits 1 if you pass it a
> bundle. Interestingly, all-dependencies servicename shows the full
> dependency tree if you pass it a bundle and the docs makes no special
> mention of bundles so I'm guessing that the failure when checking
> dependencies of bundles is a bug and that the docs are correct.
Fixed.
> s6-rc-init.html: "Typical usage" could be mis-read to have someone who
> hasn't been working with s6 for a while to think that s6-rc-init
> should be run before the catch-all logger is set up.
> index.html Discussion location listed twice.
> s6-rc.html: longrun transitions for non-notification supporting
> services should say that the service is considered to be up as soon as
> s6-supervise is forked and ./run is executed. This deals with an
> ambiguity case for non-supervision experts who may not think of the
> run script as part of the service. This might be talked about in the
> s6 docs, but it's important and should be repeated if that is the
> case.
>
> s6-rc.html: note that s6-rc will block indefinitely when starting
> services with notification support unless a timeout is set. Similar to
> the above, dry-running commands will tell you what's going on under
> the hood, but otherwise it's a bit of a black box.
Fixed.
> s6-rc: if you run `s6-rc -utN change service' and the timeout occurs,
> s6-rc -da list still reports the service down (as per the docs) but
> subsequent runs of `s6-rc -u change service' complain about not being
> able to remove the down file.
Fixed.
> s6-svc: -Dd doesn't seem to take finish scripts into account. Not a
> bug per-se, but somewhat surprising since a run script is considered
> to be part of the service. Initially I thought this was a s6-rc
> timeout bug which is why I noticed it here originally.
Well, that's the fundamental asymmetry of run and finish scripts.
The service is considered up as long as ./run is alive, but that's all:
as soon as ./run is dead, the service is considered down, whether or
not ./finish exists and no matter how long it takes to run.
It may be useful for s6-supervise to report a "./finish exited" event,
and to have an option for s6-svc to wait for that event, but I believe
this should be different from the 'd' event - 'd' should definitely be
for when ./run dies. What do you think ?
> s6-rc: Unless there's a really good reason not to, -tN should pass
> along its timeout value to the forked s6-svc and s6-svlisten1
> processes. If for no other reason than it'll keep impatient
> administrators with misbehaving processes and too-low shutdown
> timeouts from spawning tons and tons of orphaned s6-svlisten1
> processes.
s6-rc passes the "timeout-up" or "timeout-down" value to the forked
s6-svc. But yes, when there's no service-specific timeout, it would
probably be a good idea to pass along the global timeout value. Or
to pass along the min in every case.
> s6-rc: dryrun shows inaccurate commands when timeouts are involved:
> Shown:
> # s6-rc -l s6-rc-live -d -t 1000 -n0 change sleeper
> s6-rc-dryrun: /package/admin/s6/command/s6-svc -Dd -T 0 --
> s6-rc-live/servicedirs/sleeper
> actual when running the above:
> package/admin/s6-2.1.5.0/command/s6-svlisten1 -d --
> s6-rc-live/servicedirs/sleeper
> /package/admin/s6-2.1.5.0/command/s6-svc -d --
> s6-rc-live/servicedirs/sleeper
> Not sure where this is going wrong, but I bet it's related to the
> previous issue as well.
Those are actually the same. :)
s6-svc has no timeout management itself. When called with a -U|-D
option, it rewrites itself into a s6-svlisten1 command that calls
s6-svc without the option. This is what you're seeing.
> Functionality requests:
> s6-rc: it'd be nice if omitting a timeout for -n didn't throw an error
> and instead passed -t0 to s6-rc-dryrun.
It's contrary to getopt() to allow an option to either be argless or
take an arg. Think of the default dry-run option as "-n0", not "-n". :)
> s6-rc-init: remove the uid 0 restriction to allow non-privileged
> accounts to set up supervision trees. There are occasional situations
> where you have a service that you want to supervise but want to have a
> non-privileged user be able to make adjustments to that service
> without allowing that account sudoers access to your entire
> supervision tree.
I don't think removing the uid 0 restriction on s6-rc-init would
accomplish what you want. It would mean that some user has access to his
own private supervision tree along with his own complete service
database, and manages his own sets of services with s6-rc, including
a private instance of s6rc-oneshot-runner - in short, duplicating the
whole s6-rc infrastructure at the user level. It's possible, but
expensive, and I'm not convinced it would be useful.
Users can write their own source directories for service definitions,
and the admin can take them into account by including them in the
s6-rc-compile command line. It's not very flexible, but it's secure;
is there some more flexible functionality that you would like to see ?
--
Laurent
Received on Thu Jul 16 2015 - 08:40:19 UTC