Re: root svwait on unprivileged supervise
To complete my previous answer, I update the minor (the third number) when new symbols are added. So the ABI changes, but no rebuild is necessary because the old symbols are still there (with the same signature and semantics). However, new versions of software such as s6, including bugfix releases, may depend on the new symbols; I document the minimum supported version in the INSTALL and doc/upgrade.html files of these software packages. So when you're building distro packages with the new versions of the software, make sure to keep the dependencies up-to-date. -- Laurent
Re: root svwait on unprivileged supervise
While we're at it, may I ask about s6's versioning scheme? I noticed there was an ABI change in skalibs (env_mergen becoming a macro), but the Gentoo package for skalibs is currently set up to only trigger rebuilds of dependant packages if the second number changes (e.g. from 2.14.x to 2.15.x). There was no change in s6's API or ABI, so only the last number (release) will change. For skalibs, the real answer is that I'm not as cautious as I should be. I don't want to update the major version unless it's very necessary, and the changes so far have only been additions and bugfixes; but you're right that if the ABI changes, the major should change as well. To avoid that, I'll change env_mergen back to a symbol until there's another, more compelling reason to break compatibility (at which point it's a major upgrade anyway and I can make env_mergen a macro again). Thanks for keeping watch, it's a good feeling when someone notices it when I do something wrong. :) -- Laurent
Re: root svwait on unprivileged supervise
Can confirm it works. Thanks! While we're at it, may I ask about s6's versioning scheme? I noticed there was an ABI change in skalibs (env_mergen becoming a macro), but the Gentoo package for skalibs is currently set up to only trigger rebuilds of dependant packages if the second number changes (e.g. from 2.14.x to 2.15.x). Em sex., 3 de mai. de 2024 às 17:59, Laurent Bercot escreveu: > > > >The cause for this is the weird dance we have to do with fifodirs and > >fifo permissions in order to grant the correct filesystem rights > > The model was actually correct, it was just a bug, that nobody > noticed because it's rare that root has to wait for a notification > from user-owned services. :) > > It should be fixed in the s6 git head. (Requires skalibs git head.) > > -- > Laurent >
Re: root svwait on unprivileged supervise
The cause for this is the weird dance we have to do with fifodirs and fifo permissions in order to grant the correct filesystem rights The model was actually correct, it was just a bug, that nobody noticed because it's rare that root has to wait for a notification from user-owned services. :) It should be fixed in the s6 git head. (Requires skalibs git head.) -- Laurent
Re: root svwait on unprivileged supervise
I have a setup where sometimes a root process will s6-svwait on a s6-supervise that is running as another UID. Unless I s6-applyuidgid -u $svscan_uid s6-svwait ..., the svwait never returns and the pipe it creates just stands there in the event/ folder until I `sudo rm` it. If it helps, the stale pipes are mode 700 and root:$svscan_gid are the owners. Stracing the supervise says opening the ftrig1 pipe fails with EACCES. Heh. That's an interesting corner case that I hadn't thought about. The cause for this is the weird dance we have to do with fifodirs and fifo permissions in order to grant the correct filesystem rights to notifiers and listeners, without allowing everyone to send fake notifications. It's clearly an awkward mechanism. I think I have a solution for it, I'll experiment. Thanks for the report. -- Laurent
