Re: runit SIGPWR support
On Fri, Feb 14, 2020 at 3:22 PM Steve Litt wrote:
>
> On Fri, 14 Feb 2020 05:18:33 -0800
> Cameron Nemo wrote:
>
> > On Fri, Feb 14, 2020 at 4:45 AM Steve Litt
> > wrote:
> > >
> > > In my computer usage, I usually need about 5 minutes to gracefully
> > > exit all my programs before powering down the computer, and I have
> > > a 40 minute UPS. If this is done at all, I'd suggest a configurable
> > > amount of time, with a visible countdown, telling the user to get
> > > his or her affairs in order, and also a way to cancel the shutdown.
> > >
> > > The only reason I see to have the computer automatically power down
> > > when signaled by the UPS is that I might not be home, but in that
> > > case waiting 5 minutes wouldn't matter.
> >
> > Most init systems allow the SIGPWR behavior to be configured.
> > This includes Upstart, systemd, and my own "little init":
> >
> > https://gitlab.com/chinstrap/linit#configuration
> >
> > I provide a guide for using linit with runit here, but the process is
> > experimental:
> >
> > https://gitlab.com/chinstrap/linit/-/blob/master/README.runit.md
> >
> > Linit is packaged in Void Linux, and void images are available for
> > LXD. Lastly I want to mention that lxc.signal.halt is not available
> > with LXD.
> >
> > Regards,
> > --
> > Cameron Nemo
>
> Hi Cameron,
>
> I'm very impressed with linit. In my 20 minute perusal it looks quite a
> bit like Suckess Init, which I like. On line 54 you have
> int linit_spawn(char * restrict path) {
>
> Is path the path to the rc file that linit forks off? I've never seen
> char * restrict before: What does "restrict" mean?
I use the term hook, which could refer to /boot, /sigpwr, or /sigint.
Roughly equivalent to an rc file.
restrict keyword is described here:
https://en.wikipedia.org/wiki/Restrict
https://stackoverflow.com/questions/745870/realistic-usage-of-the-c99-restrict-keyword
It is probably not useful in this case, but the posix_spawn API
specifies it so I used it.
>
> I notice linit responds only to a couple signals, whereas Suckless
> Init responds to:
> { SIGUSR1, sigpoweroff },
> { SIGCHLD, sigreap },
> { SIGALRM, sigreap },
> { SIGINT, sigreboot },
> { SIGILL, sigillhandle},
>
SIGUSR1: I am unaware of any linux tools which use that signal. I used
SIGPWR specifically for compat with UPS tools and lxc/lxd.
SIGCHLD: linit actually ignores this signal, which reaps the child.
SIGALRM: because childs are implicitly reaped, there is no reason to
include a tick from what I can tell. (i.e. this case never happens:
https://git.suckless.org/sinit/commit/170d599d58efee6c9be675a85c6e435d68e8a2de.html)
SIGINT: same behavior as sinit here.
SIGILL: you must have added that. I would be curious to know why.
> Actually, I think I might have put one of those in, but I don't think
> you respond to most of them: Is there a reason?
>
> Anyway, I kind of like your linit PID1.
Thanks.
The only real novel details are that:
- it calls pause() in the main loop
- uses posix_spawn() to exec from signal handlers in a thread safe manner
> Steve
Regards,
Cameron
Re: chpst -u and supplementary groups
On Mon, Aug 19, 2019 at 5:08 AM Jan Braun wrote: > > Hello list! > > Yesterday, I spent way too much time chasing down a permissions problem > caused by the fact that "chpst -u acc prog..." only sets the account's > primary group, and ignores any supplementary groups the account may be a > member of. > > TFM mentions "All initial supplementary groups are removed.", but I > failed to memorize that. (Also, what does "initial" signify here?) > > My inability to see the issue came from the fact that all other similar > programs (I'm aware of) do in fact add the supplementary groups. Watch: > > | # chpst -u test id > | uid=1003(test) gid=1003(test) groups=1003(test) > | # runuser -u test id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # s6-setuidgid test id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # su - test -c id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # su test -c id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # sudo -u test id > | uid=1003(test) gid=1003(test) groups=1003(test),4(adm) > | # Most of these (su, sudo, runuser) go through PAM. su and sudo are primarily targeted at interactive use. I found another outlier, Google's minijail0: / # chpst -u cameronnemo /usr/bin/id uid=1000(cameronnemo) gid=1000(cameronnemo) grupos=1000(cameronnemo) / # minijail0 -u cameronnemo /usr/bin/id uid=1000(cameronnemo) gid=0(root) grupos=0(root) / # minijail0 -u cameronnemo -g cameronnemo /usr/bin/id uid=1000(cameronnemo) gid=1000(cameronnemo) grupos=1000(cameronnemo) > > So now I'm wondering: > What are the use cases for not applying existing supplementary groups? It requires additional fact finding by what amounts to a shim between the OS and the service. Use cases are questionable -- why is a login session not more suitable? Workarounds and other options exist, as demonstrated above. > Should chpst apply them by default? I would rather it not. > Should chpst grow an option to (not) apply them? Depends on the implementation. > "chpst -u acc: prog..." is still free. > Or is everything as it's supposed to be, and people might need to munge > the output of "getent initgroups acc" and feed it to the -u option? Yeah let's not do this. A good implementation is possible, and has been done. > I'll be happy to try to come up with a patch (even if it's still a > fatter warning in the manpage) if people can agree here what the right > thing to do is. Nobody maintains runit, so who is taking this patch? > regards, > Jan Cheers, Cameron
Fwd: emergency IPC with SysV message queues
On Sun, May 19, 2019 at 10:54 AM Jeff wrote: > [...] > On Thu, May 16, 2019 at 09:25:09PM +, Laurent Bercot wrote: > > [...] > > Okay, so your IPC mechanism isn't just message queues, it's a mix > > of two different channels: message queues *plus* signals. > > well, no. the mechanism is SysV msg queues and the protocol for > clients to use to communicate includes - among other things - notifying > the daemon (its PID is well known) by sending a signal to wake it up and > have it processes the request input queue. > you do not use just fifos (the mechanism), there is also a protocol > involved that clients and server use. What details need to be conveyed other than "stand up", "sit down", and "roll over" (boot, sigpwr, sigint)? > > Signals for notification, message queues for data transmission. Yes, > > it can work, but it's more complex than it has to be, using two Unix > > facilities instead of one. > > indeed, this is more complex than - say - just sockets. on the other > hand it does not involve any locking to protect against concurrently > accessing the resource as it would have done with a fifo. > > and again: it is just an emergency backup solution, the preferred way > are (Linux: abstract) unix sockets of course. such complicated ipc is > not even necessary in my case, but for more complex and integrated > inits it is. that was why i suggested in order to make their ipc > independent of rw fs access. Abstract namespace sockets have two shortcomings: * not portable beyond linux * need to use access restrictions * shared across different mount namespaces; one needs a new network namespace for different instances I am considering dropping it for a socket in /run in my supervisor. -- Cameron > > and of course one can tell a reliable init by the way it does ipc. > > > You basically need a small library for the client side. Meh. > > right, the client has to know the protocol. > first try via the socket, then try to reach init via the msg queue. > for little things like shutdown requests signaling suffices. > > > A fifo or a socket works as both a notification mechanism and a > > data transmission mechanism, > > true, but the protocol used by requests has to be desinged as well. > and in the case of fifos: they have to be guarded against concurrent > writing by clients via locking (which requires rw fs access). > > > and it's as simple as it gets. > > the code used for the msg queueing is not complicated either. > > > Yes, they can... but on Linux, they are implemented via a virtual > > filesystem, mqueue. And your goal, in using message queues, was to > > avoid having to mount a read-write filesystem to perform IPC with > > process 1 - so that eliminates them from contention, since mounting > > a mqueue is just as heavy a requirement as mounting a tmpfs. > > indeed, they usually live in /dev/mqueue while posix shared memory > lives in /dev/shm. > > that was reason that i did not mention them in the first place > (i dunno if OpenBSD has them as they usually lag behind the other > unices when it comes to posix conformance). > > i just mentioned them to point out that you can be notified about > events involving the posix SysV ipc successors. > i never used them in any way since they require a tmpfs for this. > > > Also, it is not clear from the documentation, and I haven't > > performed tests, but it's even possible that the Linux implementation > > of SysV message queues requires a mqueue mount just like POSIX ones, > > in which case this whole discussion would be moot anyway. > > which in fact is not the case, try it with "ipcmk -Q", same for the > other SysV ipc mechanisms like shared memory and semaphores. > you can see that easily when running firefox. it uses shared memory > without semaphores akin to "epoch" (btw: if anyone uses "epoch" init > it would be interesting to see what ipcs(1) outputs). > this is in fact a very fast ipc mechanism (the fastest ??), though > a clever protocol must be used to avoid dead locks, concurrent accesses > and such. the msg queues have the advantage that messages are already > separated and sorted in order of arrival. > > > You've lost me there. Why do you want several methods of IPCs in > > your init system? Why don't you pick one and stick to it? > > since SysV msg queues are a quite portable ipc mechanism that does > not need any rw access. so they make up for a reliable ipc backup > emergency method. > > > Sockets are available on every Unix system. > > these days (IoT comes to mind). but i guess SysV init (Linux) does > not use them since there might have been kernels in use without > socket support (?? dunno, just a guess). > on the BSDs this should be true since it was said that they implement > piping via socketpairs. > > > So are FIFOs. > > i do not like to use them at all, especially since they need rw > (is that true everywhere ??). > > > If you're going to use sockets by default, then use sockets, > > and you'll never need to fall back on
