Re: nosh version 1.31
Guillermo: One could instead attach controllers to the hierarchy rooted in /sys/fs/cgroup/systemd, for example by mounting it with 'mount -t cgroup -o cpu,name=systemd cgroup /sys/fs/cgroup/systemd' (not with system-manager as process 1), and things would appear to be OK: It's tempting to do that, and make the adjustments to the current control group location code. But the harsh reality I suspect is that version 1 control groups are on the way out. Let's put it this way: I am targetting Debian Linux, notorious for being behind the times, and even that has a kernel (in Debian 8 backports, admittedly) with version 2 control groups now. I'll save the idea up. But there's other, higher priority stuff to do. I've just finally turned unload-when-stopped into a simple service-control --exit wrapper, for example. (-:
Allow configurable behavior of TERM signal for runsvdir
Hi! By default, Docker sends a TERM signal to a container when you want to stop it. When runit is used as init inside a Docker container, this directly kills the runsvdir process, without really cleaning up any child processes. In newer Docker version you can configure STOPSIGNAL inside your Dockerfile to configure for example for Docker to send HUP to runsvdir. But the issue is that because runsvdir exists immediately after sending TERM to children, Docker kills the whole container before really leaving to children to terminate gracefully. So there would be two things to improve behavior inside Docker containers here: First, there could be an option to set which signal is used as current HUP signal. This could make it work in older Docker versions, as one could for example run runsvdir --hup-signal=TERM to override behavior of TERM signal. Second, after it gets HUP signal, runsvdir could wait for all children to finish before existing itself. (If they do not finish in reasonable time, Docker will kill anyway all processes with KILL.) Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Re: ftrigr bug
There's no obvious way to make it more efficient without significantly exploding the amount of code, and we're talking about a scale where a bit of n^2 is completely negligible. I've committed a patch that does exactly what you suggested, even if the code is organized a bit differently. Please tell me if it works for you. -- Laurent
