On Mon, Jul 13, 2015 at 3:20 PM, Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
> Ah, so that's why you didn't like the "must not exist yet" requirement.
> OK, got it.
> Yeah, mounting another tmpfs inside the noexec tmpfs can work, thanks
> for the idea. It's still ugly, but a bit less ugly than the other choices.
> I don't see anything inherently bad in nesting tmpfses either, it's just a
> small waste of resources - and distros that insist on having /run noexec
> are probably not the ones that care about thrifty resource management.
>
It's the (least) ugly option that I can think of. Like I said, not
great but better than the alternative. It does give some nice per-user
isolation as well if you're running multiple sub-trees.
>
> s6-rc obviously won't mount a tmpfs itself, since the operation is
> system-specific. I will simply document that some distros like to have
> /run noexec and suggest that workaround.
>
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.
>
>
> Yes, I'm going to change that. "absent" was to ensure that s6-rc-init
> was really called early at boot time in a clean tmpfs, but "absent|empty"
> should be fine too.
>
A fresh, empty tmpfs is probably cleaner than a freshly created
directory in a dirty tmpfs (like /run can be), at least if you're
running s6-svscan in non-pid1 mode.
>
> Landmines indeed. Services aren't guaranteed to keep the same numbers
> from one compiled to another, so you may well have shuffled the live
> state without noticing, and your next s6-rc change could have very
> unexpected results.
>
Everything seemed to work out ok but live-updating stuff without
adjusting the state file seemed dicy.
>
> But yes, bundle and dependency changes are easy. The hard part is when
> atomic services change, and that's when I need a whiteboard with tables
> and flowcharts everywhere to keep track of what to do in every case.
>
Yeah, that'll be a bit harder. Good luck with your whiteboarding.
>
>
> Please mention them. If you're having trouble with the tools, so will
> other people.
>
Most of the stuff has been handled with my closer reading of s6-rc -a,
plus the changes to s6-rc list. Plus simply familiarizing myself with
the tools and their output has helped a lot. I did find a few bugs,
documentation or otherwise:
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.
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.
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. I'd expect a service that timed out on
startup to have the down file since s6-rc-compile.html notes that down
files are used to mark services that s6-rc considers to be down. Maybe
make the removal of the down file the last thing the startup routine
does instead of the first since I'd consider interrupting or killing a
call to s6-rc the same as timing out (and as such shouldn't change the
reported state). -dtN has the same behavior (putting the down file in
place before calling s6-svc) but in that case erring on the side of
down feels correct.
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.
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: 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.
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.
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. Unix file permissions should limit who can make
adjustments to the non-privileged subtree so I don't think it'll open
up any additional security holes and it'll allow people to take
advantage of setup oneshots instead of needing to do runscript
gymnastics or other horribleness.
I think that's it for now.
Cheers!
--
"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 Tue Jul 14 2015 - 16:23:28 UTC