Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification
Hey,
I don't want to pick a side in the turnstile-or-not fight, so I
found something you seemed to agree on, to disagree with:
Paul Sopka schrob:
> > [...] and unless you want to make users replace their shell with
> > something like `/etc/execline-startup` as described in
> > https://skarnet.org/lists/supervision/3126.html, your proposal is going
> > to need a custom PAM module for that too.
> [...]
> My proposal [...]
> by a potential pam module that exports it's content to the users shell.
There's already pam_env to set environment variables. And from
pam_env.conf it can expand @{HOME} and presumably ${USER}, which should
be all you need to accomodate desktop stuff that expects XDG_* and
DBUS_SESSION_BUS_ADDRESS.
Everything else can and should be done via conventional places in the
file system, the way DJB intended. ;)
cheers,
Jan
signature.asc
Description: PGP signature
Re: s6/s6-rc policy for Gentoo: The logging directory
Hey, Paul Sopka schrob: > [ user services have service dir in /run and logs in /var ] > What do you think about that reasoning? Agree. Besides consistency, putting those below $HOME would also break in NFS setups where $HOME is shared among several machines. > I do not *want* to adhere to the XDG spec, it just seemed sensible to me and > nobody has provided any reason against it so far. See reason above. ;) But otherwise the correct sentiment. > Anyway, [1] made me think about why not to use a "/"-like structure under > "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point me to any > thread/list discussing that? Please don't. There's already 2 different standards for dotfiles (XDG and ~/.nameofprogram), inventing a third one is a case of https://xkcd.com/927/ (But per the above, ~/ is not apropriate anyway, so the point is moot.) cheers, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo: The logging directory
Peter Pentchev schrob:
> On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> > System supervision tree logs to to /var/log/${daemon}
> >
> > User supervision tree logs got to /var/log/${USER}/${daemon}
>
> Quick question (that you may have already thought about, apologies in
> advance): what happens if one wants to start a new daemon that has
> the same name as an already existing system user account?
> Also, what happens if a new system user account is created with
> the same name as an already configured service daemon?
Indeed. Those should be /var/log/s6/${daemon} and
/var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
any toes.
signature.asc
Description: PGP signature
Re: s6/s6-rc policy for Gentoo
Paul Sopka schrob: > An alternative would be two main bundles per user service tree, that itself > always starts on boot: > > One to start at boot time. > Another one to start on first login and stop on last login. > This seems the most elegant and efficient. Am I overlooking anything? I am not too familiar with s6 bundles (I use runit, not s6), but that sounds reasonable. > > This sounds unnecessarily complicated. Why not simply test for existence > > of a well-known entry point somewhere in $HOME and let that set up the > > user supervision tree however it sees fit (or not at all)? > > If I understand correctly, this would only be possible using instantiated > services, I like the idea and I am looking into this. Not sure what you mean by "instantiated services". But see below. > > Ugh. I hate this thinking. [...] > > It looks like I just do not have enough experience, that's why I am asking > you all on those points. You are right. Sorry for my tone, I realize I was grumpy, possibly offensively so. You took it well, thanks. :) > Using the idea I stated above, one could use different PAM modules to start > different bundles tho, e.g. an ssh bundle on ssh login, a getty bundle on > getty login, a greetd bundle on greetd login. While I don't know why one would want to differentiate between those, you probably can do that quite straightforwardly with pam_exec(8) calling a tiny script that tracks the number of active sessions (of type "$1") and calls s6-rc on zeroes. And if you want to make this machinery user-customizable, you'll need three user entry points: ~/.foo/supervisor defaulting to "s6-svscan $scandir" ~/.foo/login defaulting to "if $concurrent == 0 then s6-rc start $type" ~/.foo/logout defaulting to "if $concurrent == 0 then s6-rc stop $type" And you'll need one admin action which creates the service supervising ~$USER/.foo/supervisor (if that service doesn't exist yet). To be triggered on user account creation, or probably on login if things like ldap are involved. regards, Jan signature.asc Description: PGP signature
Re: s6/s6-rc policy for Gentoo
Paul Sopka schrob: > My claim was more about a practical, applied scenario. In the terms of: If a > user is not logged in, he simply cannot control his services. So why shall > he have an entire user supervision tree of which the sole purpose is to > allow the user to control the services running with his permission set, > running at a time he is not logged in, thus not able to control his > services? That part seems confused. The user is able to control their services by logging in and then invoking s6-whatever. > Do you see any cases where this would actually be useful in real world > applications? Replacing crond with snooze, for example. And personally, I want my ssh-agent to stay alive when I log out, so that the key is still unlocked if/when I immediately log in again. > Concerning your last point, the best I can offer for now is to have a > script, using a template dir to create the user supervision system service. > This can of course only be done by the system admin. The user can then add > whatever he wants to a previously empty bundle described in the wiki, before > invoking an "s6-user-db-update" command or similar, invoking a script that I > supply and that does the compilation and s6-rc-update command. This sounds unnecessarily complicated. Why not simply test for existence of a well-known entry point somewhere in $HOME and let that set up the user supervision tree however it sees fit (or not at all)? > on a desktop system you rarely have someone ssh'ing in. > On a server system no user will ever add heavy desktop scripts to the user > service autostart, because a) he can't use them anyway and b) they shouldn't > be there(why the heck should the sysadmin install e.g. pipewire or mpd on > such a server? Packages which would be responsible for drawing in the > required user services.) Ugh. I hate this thinking. Server/Desktop is not a binary choice. I regularly ssh into otheruser@localhost on my main machine. Sometimes I log in as otheruser and startx. Occasionally I start a vnc server as otheruser. I have an mpd instance that runs as its own user. Any desktop-only solution where people argue "you shouldn't do this on a server" is one where I'll argue "you shouldn't do this at all". > [...] > And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor. > > I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY and > the compositor at all. > > But I argue that, in case it is ran in it's server configuration, it makes > sense to supervise it, i.e. not starting it directly from the compositor. > The same can be said about notification daemons, status bars, ... You can supervise it, but the supervision tree is dependent on the compositor. If the compositor goes away, the supervision tree needs to die as well. If you start two compositors, you need to create two supervision trees, one for each WAYLAND_DISPLAY. > As you have already said this is the best example for why an additional C) > would make sense. This is where my next problem arises, imagine we now set > up another supervision tree for starting it up as soon as the compositor is > there. > > I can probably cleanly do this my reading from the socket seatd provides and > using s6-fdholder-retrieve, right? How could this be stopped cleanly upon > exiting the wayland compositor? > > The issue on how to retrieve WAYLAND_DISPLAY arises again. > > This could be solved by starting the "graphical" s6-svscan from the > compositor, e.g. Hyprland, even though the compositor is not supervised, > once it crashes it takes everything depending on it down with it anyway, so > this doesn't matter. The biggest issue is, yet again, how to stop the > services cleanly on exiting the compositor. Any ideas? * create a unique live dir from the "graphical" template * start compositor ** in compositor's autostart, have something that exports the WAYLAND_DISPLAY and calls s6-rc start ** (if possible) register s6-rc stop as an exit hook with compositor * once the compositor exits, tear down everything. Or just use X11, which properly separates Xserver from WM, avoiding any problems caused by uncooperative compositors. > Another issue I see is that the user of the desktop system gets a third > supervision tree he has to manage. And for most of the more casual people it > is probably hard to correctly understand and use the differences between C) > and B), in the little free time they can invest into linux. If it needs a display, it goes into C, otherwise into B. > There is another alternative I see: starting the compositor itself as a user > service. I have to think about how feasible this is. What do you think? Feasible, sure. Good idea, probably not. A misconfigured compositor restarting over and over again is a pain to fix. > This brings me to the final problem which the alternative mentioned above > solves already: The user services manage a couple of things, namely the > XDG_RUNTIME_DIR and
Re: OpenVPN runit service flooding tty
Laurent Bercot schrob: > IIRC, 1. is intrinsic to runit, there is no way to redirect the default > logging, [...] There is: the default logging simply goes to runsvdir's stdout. You can connect that in /etc/runit/2 to wherever you like. > a runit service should use the runit logging facility. That is something > you should report and suggest to the maintainer of the openvpn service > in Artix. I couldn't test easily whether openvpn logs to stdout or stderr, but that's a common pitfall: runit expects logging output on stdout. Thus a /run file should usually include a "exec 2>&1" line to ensure logs actually go to the log service. regards, Jan signature.asc Description: PGP signature
Re: Following log directories
John W Higgins schrob: > I meant nothing towards s6 - but daemontools does not deal with leap > seconds (or at least it cetainly looks that way from my foolish viewpoint). Daemontools assumes that time(3) returns TAI-like time (seconds actually elapsed since the epoch). That's a rather sane approach that allows to do time calculations with complete disregard for leap seconds and time zones. And for communication with the user, you consult tables listing the effects of the erratic movements of the earth and politicians, respectively. These tables are usually shipped in the "right/" tzdata directory, used by setting e.g. TZ=right/Europe/Lisbon . Unfortunately, POSIX mandates that time(3) returns UTC-like time instead (arithmetic difference between the epoch and now, calculated as if leap seconds didn't exist). That's what most systems do, also because the NTP protocol runs on UTC, and NTP clients by default set computer's clocks to UTC-like timestamps. The obvious disadvantage is the need to keep leap seconds in mind when doing any calculation, or to accept being wrong by up to 27 (as of now) seconds. And then consult tables for politician effects only, e.g. TZ=Europe/Lisbon or equivalently TZ=posix/Europe/Lisbon . So yes, daemontools does not deal with leap seconds, because that's the smart thing to do. ;) At least if you can configure your NTP client to support that scenario. > I was just pointing out that there is a second check which may need to be > applied to make sure the viewer is providing the information one believes > they are seeing. Yes. I hope I could provice some useful/interesting background. Cheers, Jan signature.asc Description: PGP signature
Re: Logging in a web server context
Hey, Carl Winbäck schrob: > Is it possible when using s6-svscan/s6-supervise to somehow arrange so > that a daemon’s stdout is sent to one logdir and stderr to another > logdir? I'm not completely sure about s6, but runsv (from runit) hands only the stdout of the ./run script to the logger, and passes the stderr out of it's own stderr. This allows you to nest two runsv instances, one for each output channel: $ find -type f | xargs head -n 99 ==> ./inner/log/run <== #!/bin/sh mkdir -p stdout svlogd -t stdout ==> ./inner/run <== #!/bin/sh echo stderr >&2 echo stdout sleep 10 ==> ./log/run <== #!/bin/sh mkdir -p stderr svlogd -t stderr ==> ./run <== #!/bin/sh exec runsv inner 2>&1 $ timeout 11 runsv . $ find -name current | xargs head ==> ./inner/log/stdout/current <== @40005ee4a23f2591745c stdout @40005ee4a24925b79614 stdout ==> ./log/stderr/current <== @40005ee4a23f257ae304 stderr @40005ee4a24925b76f04 stderr $ Translation to s6 is left as an exercise to the reader. > One tricky aspect of logging that is specific to web servers is that > they emit two different categories of messages: > > a) Errors and warnings > > b) Info about page requests[2] You could also run the webserver with stderr redirected to stdout, and let s6-log/svlogd filter the messages into one of two logdirs: $ printf 'stdout\nstderr\n' | s6-log -- '-.*err' t ./stdout f t ./stderr $ head std*/current ==> stderr/current <== @40005ee4acd00efdfbe9 stderr ==> stdout/current <== @40005ee4acd00efd6f5e stdout However, that's a brittle solution, because it relies on you creating correctly-matching filter rules. Depending on the webserver's output, it might still be feasible, but I recommend the other approach. HTH & cheers, Jan signature.asc Description: PGP signature
Re: runit SIGPWR support
innerspacepilot schrob: > I have checked openrc and busybox - both support SIGPWR. > > So I see no reason to change lxd behaviour, unless some realworld > software uses SIGPWR. *sigh* We've been here before. The Linux kernel uses SIGPWR to tell init "there's a power failure imminent". There's a difference to "please shutdown the system", even if (current versions of) busybox and openrc choose to shutdown the system when told about an imminent power failure. Laurent (imho correctly) argues that e.g. suspend-to-disk would be a better reaction when faced with an imminent power failure, and therefore refuses to declare that his init will shutdown the system when getting SIGPWR. The people who think adjusting lxc.signal.halt is too much effort would like inits to standardize on a signal for initiating shutdown. That would indeed be nice. But the only (catchable) signal that's out of the question for that purpose is, indeed, SIGPWR. Because the most relevant realworld software, the Linux kernel itself, has already fixed SIGPWR for a different purpose. cheers, Jan signature.asc Description: PGP signature
Re: s6 usability
Laurent Bercot schrob:
> No, you're falling for the pretext - because this is only the current
> pretext they're using. Debian *does not provide* a POSIX-compliant cd
> binary, so their claims at POSIX compliance are just lies.
Including execline's (non-compliant) cd would preclude them from
becoming more POSIX-compliant if somebody actually bothers to provide a
POSIX-compliant cd in the future.
> The current version of execline includes POSIX-compliant cd and wait
> binaries, and the next one will also include a POSIX-compliant umask
> binary. Then we shall see what new excuse they find not to put execline
> binaries in the default PATH.
Oh, hey, that somebody is you. Awesome! So shipping that execline will
actually increase POSIX compliance in Debian. :)
So let's wait and see what happens.
I haven't had any reason to suspect any Debian Developers are/were
acting insincerely in dealing with Debian issues. Bad at communication,
annoyingly stubborn, overly pedantic, plain misguided: yes, but afaict
always honest¹.
I'm sorry you feel differently. :(
> Adélie Linux *actually* aims for full POSIX compliance and passes more
> VSX-PCTS2003 tests than any other Linux distribution. It includes all
> execline binaries in /bin. No VSX tests are failed because of that.
I guess that just means that
find . -type d -exec cd {} \; -exec foo {} \;
(or similar for umask) is not part of the tests. ;)
> https://lmgtfy.com/?q=s6-log=1
Ewww, no, just no.
That's far too slow, and not deterministic.
> $ doc s6-log
> and you'd have your favorite browser auto-launched on the local s6-log.html
> page.
Yes. The lack of that is exactly my issue with the s6 docs.
> *That* would be software with some real added value, and maybe it would
> start the much-needed transition away from antiquated nroff pages.
>
> ... and since nobody else is ever going to write it, maybe I should. :(
Maybe. I don't see /much/ benefit in having hyperlinks and colors for
manpage-like docs.
However, I very much see the danger that people will start writing crap
instead of manpages-in-html once you tell them that "this is going to be
rendered by a browser".
One reason why GNU info docs are virtually unusable to me is because
they're a twisty little maze of tiny nodes hyperlinking each other, and
I found it impossible to concisely read stuff once from beginning to end
like I'd do with a new manpage.
And that's just hyperlinks. Some people will undoubtedly start doing
unprofessional things with images and Javascript and loading stuff from
the network, and then usability is completely out the window.
Man pages are not about nroff, but about having a standard template on
how to document things. But nroff serves as a filter that prevents
people from throwing random things into the man database. ;)
I think writing manpage-style docs in a simple markup language and then
compiling to nroff/html/pdf/... is the better aproach.
And then your "doc" command is just a slight variation on
"$BROWSER /usr/share/doc/html/$1", if you want it.
> I am currently experimenting with such a thing. The *exact* runit
> interfaces are difficult to provide, [...]
> The goal isn't to mimic runit, the
> goal is to help runit users transition to s6.
Well, to me, the litmus test would be whether my
runsvdir -P /etc/service ''
and various ./run scripts that use chpst and sv up/down/start/stop
result in a working supervision setup with the s6 versions of
runsvdir/chpst/sv.
The lack of config file for the logger is annoying. But since runit uses
it's own matching language, and s6-log uses posix extended regexps
(thanks!), the config file wouldn't be compatible anyway.
I shall be looking forward to the results of your experiments. :)
> I realize, from this conversation and others, that I need to write an
> additional documentation page, to be read even before the s6 overview,
> that explains what piece of the s6 ecosystem does what.
Yes, please. It's been confusing to have s6 (the supervision suite)
containing a bunch of s6-prefixed binaries, and then having a bunch of
other loosely related things also with s6- prefixes. Contributes greatly
to my "too many binaries to keep in memory" issue.
> > Needing to *understand* execline wasn't my misconception, nor worry. But
> > when I'm told that a runit-lookalike depends on bringing its own
> > scripting language along, then that sounds more like systemd and less
> > like djb to me. :(
>
> That is only until you realize [...] I understand you may have been
> burned by crappy software before, but s6 is not like that.
Yes. I think and hope that I was careful in wording anything about "s6
complexity" as *impressions* that I got by reading the docs , not as
things I believe actually apply, if you can spot the difference.
When I look at runit, I see a system that's obviously simple (yay).
When I look at s6, there are so many parts that I *cannot tell* whether
each part is reasonably simple and
Re: s6 usability
Colin Booth schrob:
> > If you're referring to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> > then, well, you are fighting against POSIX. There's little choice for
> > Debian in the matter. Taking a hardline stance on such "legal" issues is
> > part of their identity as a distro.
> >
> It doesn't help that neither Adam nor Jakub read the documentation for
> the execline equivalents for cd, umask, or wait.
Why would you say that? They effectively only claim that execline's
cd/umask/wait binaries don't conform to the POSIX specification for
cd/umask/wait. And I think that's uncontroversally true.
> That or they don't know what 'execs into' means.
POSIX requires:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
| However, all of the standard utilities, including the regular built-ins
| in the table, [...] shall be implemented in a manner so that they can be
| accessed via the exec family of functions as defined in the System
| Interfaces volume of POSIX.1-2008 and can be invoked directly by those
| standard utilities that require it (env, find, nice, nohup, time,
| xargs).
i.e, if you call
execvp("cd", "cd", /* any other args, */ NULL);
, POSIX says you MUST get the behaviour documented at
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
. And if /bin/cd is execline's cd, then you don't.
There's also the imho sensible rationale of e.g.
| find . -type d -exec cd {} \; -exec foo {} \;
| (which invokes "foo" on accessible directories)
for that requirement, even if these are admittedly rare cases.
See Message-ID:
here on the list, from Jonathan de Boyne Pollard for more details.
> Within the context of a shell the builtin will always* take precedence.
True, but not the controversial issue.
> [placing binaries]
> Have you ever considered slashpackage ;)
>
> In all seriousness though this, with the exception of dropping the s6-
> prefix (and the prefix-appender binary I guess), is what slashpackage
> does. /bin stays uncluttered, commands end up in a PATH-able place, and
> if you want to surprise any systemic shell scripts you have you can
> symlink in replacements to the default PATH.
Yes, I'm aware of that. Unfortunately, I'm not aware of a unix distro
usable for my general needs implementing /package as their packaging
scheme.
Nix/NixOS does something similar, and is on the short list of distros
I'll consider if Debian goes ahead with the systemd madness.
And FWIW, if I were to create my own distro/OS, I'd do away with $PATH
entirely and have people union-mount stuff into /bin .
> > P.S: I stumbled over this execline oddity:
> > | dollarat -0 -d a # separates by \0
> > | forbacktickx -0 -d a var {gen...} loop... # splits on a
> > IMHO, both should be an error, but at least treat them the same.
> >
> As per the docs for forbacktickx:
> -0 : accept null characters from gen's output, using them as delimiters.
> If this option and a -d option are used simultaneously, the rightmost
> one wins.
Yes, and as per the docs for dollarat:
-0 : use the null character as separator. Any -d argument will be
ignored.
They're both working as advertised. But they have *different* rules for
resolving the case where both -0 and -d are given.
I think that's a lack of UI consistency, and would consider it a bug in
my software.
(And, as I said, I think the best response to getting both -0 and -d
would be erroring out, but that's just an aside.)
cheers,
Jan
signature.asc
Description: PGP signature
Re: s6 usability
Steve Litt schrob: > > From a Linux distribution perspective, there's also the question of > > if s6 can be made a drop-in replacement for daemontools, [...] > > In my opinion, 99% of all people currently using daemontools are highly > technically proficient and could easily either rename commands or > prepath to a directory containing prefixless symlinked synonyms. IMHO > if the distro does it, they'll find a way to screw it up. And even if > the distro does it right, it will screw that 1 in a million people > (like me) who occasionally use daemontools and s6 on the same box, > switching between them regularly. I find these claims to be rather unplausible, given my Debian experience. The Debian way would be creating a package "s6-daemontools" containing just the symlinks from foo to s6-foo and declaring the following package relationships: Depends: s6 Conflicts: daemontools Provides: daemontools That is, when s6-daemontools is installed: s6 must also be installed, daemontools must not be installed, but daemontools is treated as installed for dependency purposes. Then, you can choose to install s6 and daemontools together, getting the default naming for each. And I can install s6-daemontools and get tai64n/tai64nlocal binaries that produce correct timestamps despite my kernel clock being set to UTC. (That is, the ones from s6.) And every dependency on "daemontools" will be fulfilled, by exactly one of either djb's daemontools, or s6 plus the symlinks in s6-daemontools. See espeak-ng-espeak for a real package like that. This is hardly rocket science, and has been done for *decades* by now. Maybe non-Debian(-derived) distros are in the business of doing stupid sh*t, but then you should either switch to a sane distro or be building your own system. It's certainly no reason to refuse to consider the "s6 as daemontools" concept. Or to insist that people must setup the symlinks themselves. Onwards: Comparing the debian daemontools package with s6 gives: | $ dpkg -L daemontools | grep /usr/bin/ | sed -E 's_/usr/bin/_/usr/bin/s6-_' | xargs ls -1 | ls: cannot access '/usr/bin/s6-multilog': No such file or directory | ls: cannot access '/usr/bin/s6-pgrphack': No such file or directory | ls: cannot access '/usr/bin/s6-readproctitle': No such file or directory | ls: cannot access '/usr/bin/s6-svscanboot': No such file or directory | /usr/bin/s6-envdir | /usr/bin/s6-envuidgid | /usr/bin/s6-fghack | /usr/bin/s6-setlock | /usr/bin/s6-setuidgid | /usr/bin/s6-softlimit | /usr/bin/s6-supervise | /usr/bin/s6-svc | /usr/bin/s6-svok | /usr/bin/s6-svscan | /usr/bin/s6-svstat | /usr/bin/s6-tai64n | /usr/bin/s6-tai64nlocal | $ As Laurent said in the other mail: > s6-setsid can be symlinked as pgrphack [...] > s6-log can be symlinked as multilog. That leaves only readproctitle and svscanboot. The latter is just clearing env, setting $PATH and executing svscan /service 2>&1 | readproctitle service errors: . with 400 dots, according to the manpage. But I don't think there's an equivalent of readproctitle in s6. Plus, there remains the issue of non-compatible supervise directories. I don't think the above packaging scheme is valid if it would mean services (with their existing supervise dirs) fail to work because the supervise(8) implementation got switched from djb to s6 or vice versa. But in my quick testing they actually could re-use each other's supervise dir without tripping over the other implementation's artifacts.¹ Laurent, is that something that should work/you are willing to support? In that case, readproctitle would be the only remaining obstacle. regards, Jan ¹ They would not recognize each other's locking, however. signature.asc Description: PGP signature
Re: s6 usability
Hey,
and sorry for taking so long to reply.
Laurent Bercot schrob:
> > 1) Debian ships with a working and maintained runit-init package. It
> >provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
> >Debian packages. s6-linux-init and s6-rc are not packaged in Debian.
>
> I hear you. Unfortunately, I have no control over what Debian does.
> Debian isn't even able to ship a not-broken execline package, so I'm at
> a loss on what to do with them. I'm working on a version of execline that
> they *might* accept to package correctly,
If you're referring to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
then, well, you are fighting against POSIX. There's little choice for
Debian in the matter. Taking a hardline stance on such "legal" issues is
part of their identity as a distro.
> but it's doubtful as long as
> the people in charge are prejudiced against the "lots of small binaries
> in /bin" approach. :(
I don't think that's the real issue. POSIX saying "the cd/umask/wait
shell builtin must also be exec()able" is. Or execline's desire for
binaries with those names and different behaviour, depending on your
viewpoint.
> > 2) runit has manpages. s6 has HTML. :(
>
> This is far from the first time I hear this, so it would be foolish to
> ignore it, but I *really* have a hard time understanding how in 2019 it's
> so difficult for people to launch a browser to read a web page.
It's not difficult launching the browser, it's difficult getting to the
correct webpage. Compare
| $ elinks /usr/share/doc/s6/s6-log.html
with a hypothetical
| $ man s6-log
and count keystrokes. (And then look up the K key in vim. ;)
The main advantage of manpages is that they are in a well-known place
and therefore instantly found. The displaying itself makes hardly a
difference. Especially since, thankfully, your html mimicks the man page
conventions wrt sections and so on.
Something like djb's /doc (thanks, Jonathan!) would scratch my itch too,
but as long as that's not in widespread use, I prefer man over html.
(I also have several rants about html/browsers/JS available on request,
but that's rather tangential to the issue of *finding* documentation.)
> [... 3) ...]
> The number of executables is a choice; I like to have more, smaller,
> executables than less, bigger ones. [...]
> So, I suppose it comes down to individual preference there.
I agree, it's probably personal UI taste. To me, a good metric is the
"fanout" of possible options:
When I want to call something runit-related, I got
* chpst: change process state
** -u: user
** -n: nofiles
...
- sv: manipulate a service
** up
** down
** term
...
- runsvsupervision implemention
** runsv one service
** runsvdir a dir of services
- sv- my custom scripts
** sv-errors show the readproctitle logs
...
If any point in the tree, there's 7±2 children I can find by
tab-completing/glancing at a man page, then I can probably navigate the
whole thing pretty quickly.
On the other hand:
| $ ls /usr/bin/s6* | cut -d- -f 2 | uniq | wc -l
| 39
Even if there's still some related commands (e.g. 3x s6-sudo*), that
number is not coming down to a point where I can keep everything in
my head.
> Would a generic "s6" command, that takes alternative syntax and rewrites
> itself into "internal" commands, help? It could emulate runit syntax,
> among other things.
>
> s6 runsv ... -> s6-supervise ...
> s6 sv ... -> s6-svc ...
> s6 chpst ... -> various s6-prefixed process state change commands
Probably yes, but if you are doing that, then why don't you look at
argv[0] and provide the runit interface proper? :D
(Or provide runsv/sv/chpst/.. as individual binaries, since you prefer
those.)
But outside of supervision, I notice that you are reimplementing a
lot of small programs. As long as they're mostly command-line compatible
with their inspiration, I think such a "s6" executable would enable a
nicer UI for s6-{linux,portable}-utils and the s6 djb reimplementations:
Have your binaries in /usr/lib/s6/ (or wherever), and named without the
"s6-" prefix. Have a "s6" binary multiplexing to these on its first
argument. That way, a user can choose any of:
| $ s6 cat foo
|
| $ PATH="/usr/lib/s6/:$PATH"
| $ cat foo
|
| # ln -sf /usr/lib/s6/cat /bin/cat
| $ cat foo
(And possibly a s6-cat compatibility symlink somewhere.)
This is similar to busybox (except for the reverse goal :) and allows
individual customization, while keeping /bin/ uncluttered by default.
And with all those reimplementations out of the way, maybe the remaining
binaries are few enough that I can actually remember them. Of course, if
you then want to rename s6-supervise to runsv, and s6-svscan to
runsvdir, that might even work. ;)
> > 4) s6 seems more complex (hello execline!), and I don't (yet?) see any
> >benefit/feature I'd appreciate except minimizing wakeups.
>
> This,
Re: runit patches to fix compiler warnings on RHEL 7
Hi, Laurent Bercot schrob: > - My opinion is that the most sustainable path forward, for runit > users who need a centrally maintained supervision software suite, is to > just switch to s6 - and it comes with several other benefits as well. As a relatively new convert to supervision software, my reasons for preferring runit over s6 are, in order of priority: 1) Debian ships with a working and maintained runit-init package. It provides pid 1 and hooks into /etc/rcS.d/* to integrate with other Debian packages. s6-linux-init and s6-rc are not packaged in Debian. 2) runit has manpages. s6 has HTML. :( 3) s6 executables are somehow worse named than runit's. This may be highly subjective, but I can recall and recognize the runit commands far easier than the s6 ones. Possibly it's the "s6-" prefix getting in the way of my brain pattern matching on visual appearance of glyph sequences. This point is exacerbated by #2 and the number of s6 executables. Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the historical reasons, but still. 4) s6 seems more complex (hello execline!), and I don't (yet?) see any benefit/feature I'd appreciate except minimizing wakeups. OTOH, an active and responsive upstream is obviously a big plus for s6. > - But again, I'm not impartial, and alternatives are a good thing. > So no matter what individual decisions are made, it would definitely be > a net positive if the exact state and workflow of runit could be > clarified, and if a real development/maintenance structure was in place. Agreed. Brainstorming possible ways forward: A) Gerrit Pape becomes more active in maintianing runit, at least acknowledging patches posted here. B) Somebody else steps in as (co-)maintainer. C) We get a dumping ground (wiki or somesuch) for patches to allow - contributors to publish their patches (after discussing them here) - users to easily find and download patches they'd be interested in - Gerrit Pape to review and apply patches at his leisure when he feels like making a new release. D) The maintainers of distros shipping runit work out a patch-sharing scheme among them. Just my 0.02€, I hope it helps. cheers, Jan signature.asc Description: PGP signature
Re: chpst -u and supplementary groups
Laurent Bercot schrob: > I don't think the historical behaviour is a *bug*, because the > historical behaviour is documented and conforms to its documentation. Well, let's say "misfeature" ;) > It also comes from a time when supplementary groups weren't used as > much as they are today. > > It's just that not having supplementary groups can defeat intuitive > expectations when performing a group permissions check. That does not > happen every day, but it does happen sometimes. s6-setuidgid had the > same behaviour as setuidgid until I got bitten by that very problem, > at which point I realized that "user identity" is not only uid and gid > as it is for files, but also supplementary groups, and so I added > supplementary groups support to s6-*uidgid. But it had been years > until I found it necessary. Ok, that's the kind of answer I was hoping for, thanks. > So, YMMV. I'd say supplementary groups support is useful and allows > the tool to better match user intuition, so it has value. But is it > *mandatory* for correctness? You decide. I don't need to decide that. :) I already knew that *I* needed supplementary group support. The only question was whether I should implement it in runit's source code, or by piping the output of getent through sed, and writing "chpst -u `userid acc` prog..." in my runscripts as a matter of habit. And now the former sounds like the more reasonable course of action. I'll go have a look at the code... cheers, Jan signature.asc Description: PGP signature
Re: chpst -u and supplementary groups
Cameron Nemo schrob: > Most of these (su, sudo, runuser) go through PAM. > su and sudo are primarily targeted at interactive use. As a shell junkie, I don't subscribe to the viewpoint that there's a measurable difference between "interactive use" and "scripting". ;) > > 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. That's not a use case, that's just the KISS ssoftware design principle. But are there actually reasons for wanting to *avoid* a user's supplementary groups, implementation issues aside? > Use cases are questionable -- why is a login session not more suitable? I'm sorry, I don't understand. What's a login session? > Yeah let's not do this. A good implementation is possible, and has been done. > > [...] > > Nobody maintains runit, so who is taking this patch? Dmitry Bogatov has been quite active in runit integration for Debian during the last year or so. This is what vexes me about the daemontools family. Apparently it's so easy to reimplement them that people keep doing that. Instead of working together to get one implementation polished enough to make a big unix distro use it by default. cheers, Jan signature.asc Description: PGP signature
Re: chpst -u and supplementary groups
Jonathan de Boyne Pollard schrob: > > 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. > > > Then you are not aware of Bernstein daemontools, where setuidgid does not. > (-: Well, I am aware of their existance, but I've never used them, only various descendants. I even suspected they might not handle supplementary groups, because e.g. s6-envuidgid introduces GIDLIST to deal with them. > Setting only one group was the behaviour of the original tool. Setting the > supplementary groups as well is behaviour that others added to their > toolsets later. Bruce Guenter (in daemontools-encore) and I added it as an > optional behaviour for setuidgid. Yes. Apparently everyone re-implementing daemontools does something like this. So that brings me back to my original question: is there consensus that the historical behaviour is a bug? Or are there valid use cases¹? cheers, Jan ¹) Besides when the account has no supplementary groups, obviously. signature.asc Description: PGP signature
chpst -u and supplementary groups
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) | # So now I'm wondering: What are the use cases for not applying existing supplementary groups? Should chpst apply them by default? Should chpst grow an option to (not) apply them? "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? 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. regards, Jan signature.asc Description: PGP signature
Re: [PATCH] svlogd: implement option to use alternate config file
Patrick Steinhardt schrob: > Yeah, I thought about using a symlink here, too. The main reason > why I didn't want to do this is to keep configuration and data > separate from each other. It honestly feels a bit weird to me to > configure the logger in /var/log/$service -- doing so in > /etc/sv/$service/log seems like the more obvious location to me > and can be cleanly achieved with this new option without > requiring a symlink. I agree it feels weird. I expect to be able to rm -r /var/log/$foo to get rid of logs, without accidentally losing configuration. My standardized log/run script thus contains (among other things): | if [ -e main-config ] && [ ! -e main/config ] ; then | ln -s "`realpath main-config`" main/config | fi I think that's a simpler (and therefore better) way to move the config location than extending svlogd's C code. And I likely will s/main/$i/g and put a | for i in main foo bar ; do | ... | done loop around that code once I need several logdirs with individual configuration. I don't see how your -c option would achieve that. regards, Jan signature.asc Description: PGP signature
