On Mon, Jul 13, 2015 at 3:20 PM, Laurent Bercot <ska-skaw...@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