Re: runit SIGPWR support
Fri, Feb 28, 2020 at 07:39:47AM +0100, Jan Braun wrote: > 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. The Linux kernel never sends SIGPWR to init on most platforms. Grepping the source, there are only about two places where SIGPWR can be sent to the init process from the kernel: machine check exception on S390, and some power-related hardware failure indication on SGI workstations. I'm not familiar with either of those but I suspect in both cases the signal is expected to initiate immediate shutdown. Otherwise, why would they signal init. Just for reference, I checked apcupsd sources. It does include an example of sending SIGPWR to init when some UPS event arrives, but it's just an example, and in that setting spawning some script would be a better approach anyway. The same applies to pretty much anything else in userspace that might be monitoring power supply. It should not be signalling init, it should have some sort of a configuration event handler. Unless it's matter of principle, hard-coding SIGPWR as a shutdown signal sounds like a decent idea to me, at least on Linux. LXD and similar containers might be the only class of applications for which signalling init like that actually makes sense. The distinction between SIGINT for reboot and SIGPWR for shutdown does not sound awful either.
Re: The "Unix Philosophy 2020" document
Sat, Dec 28, 2019 at 06:41:56PM +0100, Oliver Schad wrote: > > The reason I think it's mostly useless is because the only use case > > for cgroup supervision is supervising double-forking daemons, which > > is not a very smart thing to do. A much better approach is to get rid > > of double-forking and then just directly supervise the resulting long > > running process. > > I can't think of any other cases where it would be useful. > > I definitly have to correct you: cgroups are *NOT* designed to catch > wild forking processes. This is just a side-effect ot them. Er, that whole quoted part, including the last sentence, is about using cgroups to supervise processes. Not about the use of cgroups in general. I can't think of any other use cases where cgroup supervision would be useful, other than for double-forking daemons. Also, wrt process supervision, calling it a side effect is bit misleading. The interfaces are not really made for that kind of use at all. Strictly speaking, anything doing kill `cat .../cgroup.procs` is racy and unreliable. Including that runcg tool that I wrote. In practice, the race is pretty much irrelevant, but it's still there, inherent to the interfaces.
Re: The "Unix Philosophy 2020" document
Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > Well, for me, cgroups is clearly a lack to s6. Using it for every > process like systemd do have no sense, but in some case it can be > useful to protect e.g an "over-eat" allocation memory by a program > (in particular over a server). Minor note on this. Resource limiting with cgroups does not require any explicit support from s6, or any external tools for that matter. Literally just `echo $$ > $cg/cgroup.procs` in the startup script is enough, assuming the group has been created (mkdir) and the limits have been set (bunch of echo's). The whole thing regarding cgroups in systemd is really about a very different problem: supervising broken services that exit early and leave orphaned children behind. If you only want to implement cgroup-based resource limiting, it can be done with current s6 just fine. Also with runit, bare sysvinit, busybox init and pretty much anything else than can run shell scripts. Even suckless tools probably.
Re: The "Unix Philosophy 2020" document
Sat, Dec 28, 2019 at 01:46:08AM -0500, Steve Litt wrote: > * No if any code within the s6 stack must be changed. So much good > software has gone bad trying to incorporate features for only the > purpose of getting new users. It does not require any changes to s6. That's a major point I'd like to demonstrate with this tool. A 200 C LOC external tool is enough to let any process supervisor become a cgroup supervisor, on case-by-case basis, just by chain-execing the tool with the application being supervised. What the tool itself does is fork-spawning the chained application and then waiting until cgroup is empty. While also proxying signals. For the supervisor, it looks and behaves like a regular long-running process. The supervisor does not need to know anything about cgroups. The reason I think it's mostly useless is because the only use case for cgroup supervision is supervising double-forking daemons, which is not a very smart thing to do. A much better approach is to get rid of double-forking and then just directly supervise the resulting long running process. I can't think of any other cases where it would be useful.
Re: The "Unix Philosophy 2020" document
Fri, Dec 27, 2019 at 07:23:09PM +0800, Casper Ti. Vector wrote: > I also wonder if someone on this mailing list is interested in actually > implementing a cgroup-based babysitter as is outlined in the post, > perhaps packaged together with standalone workalikes of the cgroup > chainloaders (`create-control-group' etc) from nosh? I am still quite > a newbie to actual system programming in C... https://github.com/arsv/minibase/blob/master/src/misc/runcg.c It's really simple. I don't think a tool like this has any actual uses, other than in arguments with systemd fans, but I guess that alone could justify its existance.
Re: The "Unix Philosophy 2020" document
Fri, Dec 27, 2019 at 04:29:13PM -0500, Steve Litt wrote: > What is slew? I'd guess this thing: https://gitlab.com/CasperVector/slew
Re: [Announce] s6.rc: a distribution-friendly init/rc framework
Fri, Mar 23, 2018 at 10:51:57AM +, Laurent Bercot wrote: > Bear in mind that - this is a simplified, but descriptive enough view > of the political landscape of the current Linux ecosystem - distribution > maintainers are *lazy*. They already know systemd, or openrc, or > sysvinit; they don't want to put in more effort. They don't want to have > to significantly modify their packaging scripts to accommodate a wildly > different format. In their defence, I don't think any mainstream distribution makes this kind of modifications easy. IMO it's safe to assume a new init system means a new distribution (possibly derived from something larger). > For instance, instead of having to provide s6-rc source definition > directories for services, they would provide a descriptive file, > similar to systemd unit files, that would then be automatically > processed and turned into a set of s6-rc definition directories. Extra layers generally make things harder to work with, not easier. Whoever may be building something new with s6 would probably benefit more from a reference system that's simple enough to understand and which could be used as a base for extending into a full blown distribution. Having examples at hand would likely matter much more than the format of service description. The reaction to the slew manual I'm afraid will likely be along the lines of "that's all cool and stuff but how do I actually run this?".
Re: [announce] buildroot-s6 0.2.0
Thu, Nov 12, 2015 at 09:29:37PM +0100, Eric Le Bihan wrote:
> Comments welcomed!
depends on BR2_TOOLCHAIN_USES_GLIBC || BR2_TOOLCHAIN_USES_MUSL looks really
strange, uClibc is typically the least problematic libc.
I can definitely build it with a uclibc toolchain, all it needs is -lrt
in skalibs configure when testing for posix_spawn* and later whenever -lskalibs
is used.
It does not work though. What I have so far is this:
execve("/usr/sbin/s6-echo", ["s6-echo", "--", "Starting system."], ...)
execve("s6-echo", ["s6-echo", "--", "Starting system."], ...)
execve("s6-echo", ["s6-echo", "--", "Starting system."], ...)
execve("s6-echo", ["s6-echo", "--", "Starting system."], ...)
execve("s6-echo", ["s6-echo", "--", "Starting system."], ...)
...
and it keeps repeating that execve in an infinite loop.
That's execline running /sbin/init.
The first if and the first occurence of a { } block in that script.
Strange, but I did not look further into this yet.
> buildroot-s6 is a sandbox to play with the s6 stack and see how it could be
> integrated into the official Buildroot. It is still a work-in-progress.
The worst part will be dealing with per-package service files.
I did try doing similar thing. Ended up with all my stuff in BR2_EXTERNAL,
this way it's much easier to keep Buildroot proper up to date.
s6 hangs at shutdown
Hi, I'm trying to reboot s6-based qemu system [1] and it seems to hang at around s6-rc -ad change stage. Could anyone please point out why it can't proceed to reboot, maybe I'm doing something wrong? The system runs with s6-svscan as pid 1. I log in and initiate reboot with s6-svscanctl -i /run/service This results in s6-svc: fatal: unable to control /run/service/s6-svscan-log: supervisor not listening Shutting down system. Syncing disks. but I still have my sh, and I can see with ps that all s6-supervise have been killed except for s6-supervise getty. By this point ps shows pid 1 as foreground s6-rc -ad change foreground s6-echo Performing reboot. s6-reboot and it does not seem to proceed any further. Killing sh, getty or its supervisor does not help. Same with halt and poweroff. The init script in that system is custom/board/common/overlay/s6-init/sbin/init and reboot script is custom/board/common/overlay/s6-init/etc/rc.shutdown [1] https://github.com/elebihan/buildroot-s6
