On Thu, Jul 16, 2015 at 1:40 AM, Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
> On 14/07/2015 18:23, Colin Booth wrote:
>>
... bunch of fixes ...
Looks good.
>
>
> 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 ?
>
You're right, ./run is up, and being in ./finish doesn't count as up.
At work we use a lot of runit and have a lot more services that do
cleanup in their ./finish scripts so I'm more used to the runit
handling of down statuses (up for ./run, finish for ./finish, and down
for not running). My personal setup, which is pretty much all on s6
(though migrated from runit), only has informational logging in the
./finish scripts so it's rare for my services to ever be in that
interim state for long enough for anything to notice.
As for notification, maybe 'd' for when ./run dies, and 'D' for when
./finish ends. Though since s6-supervise SIGKILLs long-running
./finish scripts, it encourages people to do their cleanup elsewhere
and as such removes the main reason why you'd want to be notified on
when your service is really down. If the s6-supervise timer wasn't
there, I'd definitely suggest sending some message when ./finish went
away.
>
>
> 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.
>
Ah, gotcha. I was sending explicit timeout values in my s6-rc comands,
not using timeout-up and timeout-down files. Assuming -tN is the
global value, then passing that along definitely makes sense, if
nothing else than to bring its behavior in-line with the behavior of
timeout-up and timeout-down.
>
>
> 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.
>
Cool. I did my close reading on s6 commands before s6-svlisten was a
thing so I missed (well, forgot) the bit where s6-svc execs into
s6-svlisten1.
>
>
> 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". :)
>
Noted. Not to big a deal since it IS only a one-character difference after all.
>
>
> 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.
>
That's actually pretty much was what I was talking about, I'll expand
on it a bit. You have a custom service that you want to run under
supervision, that gets regular updates from developers, and for
various reasons your setup has an application user that has a very
limited scope of interaction that it's allowed to do (primarily
limited to putting code on a host and then running it). It's trivially
easy to run a setuidgid sub-tree as a service of the main tree which
allows your application user the ability to make changes to their
services without leaking privileges for the system at large. What
isn't easy is all the stuff that supervision is historically bad at,
and that s6-rc (especially the one-shot stuff) is working on fixing.
At work we have that above setup under runit, with a collection of
mid-weight shell scripts to handle interaction between deploy scripts
and runsv. The notification and listen parts of s6 duplicates about
80% of what we have, and s6-rc provides both a convenient wrapper
around s6-svc and an in-supervisor method of dealing with oneshots.
>
> 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 ?
>
Part of my job entails dealing with development servers where
automatic deploys happen pretty frequently but service definitions
dont change too often. So having non-privileged access to a subsection
of the supervision tree is more important than having non-privileged
access to the pre- and post- compiled offline stuff.
By the way, that's less secure than running a full non-privileged
subtree. Since the run and finish scripts are executed as the same
user as the supervisor, a buggy or malicious script that slips past
the administrator is going to get executed as root by the supervision
suite. Better to have a single well-audited run script that spins up
private supervision trees as supervised children, and then letting
people do whatever they want in their uid constrained bucket.
> --
> Laurent
>
Cheers!
-Colin
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Thu Jul 16 2015 - 17:22:48 UTC