On Fri, Feb 01, 2019 at 04:18:50AM +0000, Kelly Dean wrote:
> Thanks for the fix. Longrun works now, though oneshot still fails, this time with a different message:
> s6-sudoc: fatal: connect to the s6-sudod server - check that you have appropriate permissions.
>
> I guess that's related to my running all this (including svscan) as non-root. s6rc-oneshot-runner is running now, though.
>
> Should I run it as root? But then you'll be able to erase a lot more than just the contents of my home dir. ;-)
It's actually that you need to run your s6-rc call as an allowed user.
See the s6-rc-compile -u and -v options. But more about this in a sec.
>
> I do prefer that my software recognize that I'm an idiot, and refuse to do dubious things unless I specify some --force option. I've been saved countless times by programs designed with users' mental frailty in mind, and bitten countless times by the opposite.
It actually is recognizing that you're an idiot :) At least, it's
recognizing that you've misconfigured something. The s6-sudo program
connects to a s6-sudod socket (really an s6-ipcserverd socket, but
that's an implementation detail) and sends it's argv to s6-sudod.
Anyway, s6-ipcserver does ACL checks, and the problem that you're
running into is that you haven't set your rules correctly and
s6-ipcserver-access is giving you the finger.
>
> The doc for rc says its diff's view diverges from s6's view only when the service fails permanently. I suggest adding there that downing the service using svc instead of rc qualifies as a permanent failure from rc's point of view. I guess this also means that if rc is used, then svc isn't supposed to be part of the normal user interface.
That requires that s6-rc be permanently running and monitoring a lot of
stuff. As an aside, it's actually very, very handy that you can fake out
s6-rc and make changes to stuff temporarily without having to deal with
the state engine. Don't get me wrong, the state engine is really nice,
but it's a pretty heavy hand sometimes.
>
> In the docs, I see no way to ask svc whether a service is up, or ask svscanctl which services are up. But obviously rc must be able to ask, in order to do the diff. I also see no straightforward way to ask rc whether a particular service is up, other than
> s6-rc -a list | grep "^servicename$"
To get the actual state of the system I use:
`for svc in /path/to/scandir/* ; do s6-svstat "$svc" ; done'
For the state of the system as far as the state engine is concerned:
`s6-rc -a list' or `s6-rc -da list' depending on what I'm going for.
>
> If inotify were portable, would you still consider svscanctl -a to be the best design, or would you omit the -a option and auto-rescan when the scan directory changed?
`s6-svscanctl -an' is by far the nicest mechanism, not just because of
the portability, but also because it lets you stage changes and then
kick the modifications all in one go. If you need auto updating, you can
either use `s6-svscan -t MSECTIMEOUT' (I suggest five seconds, that's
the daemontools / runit way). If you want something a little fancier,
set an ionotify trigger (say, in a longrun so you know it's always going
to be around) that watches the directory and issues an `s6-svscanctl
-an' when it gets nudged.
--
Colin Booth
Received on Fri Feb 01 2019 - 05:29:10 UTC