On 13/07/2015 17:35, Colin Booth wrote:
> Those options are all bad. My workaround was to mount a new tmpfs
> inside of run (that wasn't noexec) but that made using s6-rc annoying
> due to the no directory requirement. I don't think there's anything
> inherently bad about nesting mounts in this way though I could be
> mistaken.
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.
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.
> My suggestion is for one of: changing the s6-rc-init behavior to
> accept an empty or absent directory as a valid target instead of just
> absent
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.
> Hm, either the documentation or my reading skills need work (and I'm
> not really sure which).
When in doubt, I'll improve the doc: a good doc should be understandable
even by people with uncertain reading skills. :)
> Actually, assuming you're only making bundle and dependency changes,
> it looks like swapping out db, n, and resolve,cdb from under s6-rc's
> nose works. I'd be unsurprised if there were some landmines in doing
> that but it worked for hot-updating my service sequence.
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.
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.
> Glad to hear it. So far s6-rc feels like what I'd expect from a
> supervision-oriented rc system. There are some issues that I I haven't
> mentioned but I'm pretty sure those are mostly due to unfamiliarity
> with the tools more than anything else.
Please mention them. If you're having trouble with the tools, so will
other people.
--
Laurent
Received on Mon Jul 13 2015 - 22:20:50 UTC