Re: register runsvdir as subreaper
Hi! Hm, when I read the runit man page I got scared because of its trying to reboot and halt the machine. I am not sure how will that interact with a Docker container. I also didn't want one extra process to be in every container. But you are right, it seems it might be necessary anyway. So, let 'see. I could simply then use runit as PID 1 inside a Docker image. /etc/runit/1 could be an empty script (is it even required to have it, if not needed?). /etc/runit/2 would then start runsvdir. Should it exec into it? I would then map Docker stop signal to be SIGINT, and I would create a /etc/runit/ctrlaltdel script which would gracefully call stop on all services. Or does runit already do that? If /etc/runit/stopit does not exit, then sending the SIGINT signal to runit does not do anything besides running the /etc/runit/ctrlaltdel script? Mitar On Thu, Feb 2, 2017 at 10:59 AM, Steve Litt wrote: > If you have a choice of what Docker calls as PID1, why not just have it > call the runit executable, which will call sv's for level 1 and 2 and > then run runsvdir. Then you have a PID1 that does all the right things. > > SteveT > > On Thu, 2 Feb 2017 00:34:48 -0800 > Mitar wrote: > >> Hi! >> >> It depends how once organizes its container, but it is pretty normal >> that one calls runsvdir as the PID 1 in the Docker container. So that >> Docker runtime, when it is creating the container, calls directly the >> runsvdir on one directory, which contains all the services inside the >> Docker container. >> >> >> Mitar >> >> On Wed, Feb 1, 2017 at 9:55 AM, Steve Litt >> wrote: >> > On Wed, 1 Feb 2017 12:09:01 -0500 >> > Roger Pate wrote: >> > >> >> On Wed, Feb 1, 2017 at 11:48 AM, Laurent Bercot >> >> wrote: >> >> > You want a clean process tree with a visually pleasing "ps >> >> > afuxww" output? Fix your services so they don't leave orphans in >> >> > the first place. ... >> >> > Reparenting orphans to anything else than the default is a >> >> > backwards way to solve a nonexistent problem. >> >> >> >> Name it reaperhack: >> >> reaperhack is what it says: a hack. Ideally, you should never >> >> have to use it. It is only useful when you want to supervise a >> >> daemon that results in orphans; and even then, the right thing is >> >> to report this as a bug to the author of the program leaving >> >> orphans and have it fixed. >> > >> > Am I missing something? Do containers not have a PID1? If so, what >> > runs runsvdir (with the runit init system)? What starts up whatver >> > sv script? >> > >> > Thanks, >> > >> > SteveT >> > >> > Steve Litt >> > January 2017 featured book: Troubleshooting: Just the Facts >> > http://www.troubleshooters.com/tjust >> >> >> > -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Re: register runsvdir as subreaper
Hi! It depends how once organizes its container, but it is pretty normal that one calls runsvdir as the PID 1 in the Docker container. So that Docker runtime, when it is creating the container, calls directly the runsvdir on one directory, which contains all the services inside the Docker container. Mitar On Wed, Feb 1, 2017 at 9:55 AM, Steve Litt wrote: > On Wed, 1 Feb 2017 12:09:01 -0500 > Roger Pate wrote: > >> On Wed, Feb 1, 2017 at 11:48 AM, Laurent Bercot >> wrote: >> > You want a clean process tree with a visually pleasing "ps afuxww" >> > output? Fix your services so they don't leave orphans in the first >> > place. ... >> > Reparenting orphans to anything else than the default is a >> > backwards way to solve a nonexistent problem. >> >> Name it reaperhack: >> reaperhack is what it says: a hack. Ideally, you should never have >> to use it. It is only useful when you want to supervise a daemon that >> results in orphans; and even then, the right thing is to report this >> as a bug to the author of the program leaving orphans and have it >> fixed. > > Am I missing something? Do containers not have a PID1? If so, what > runs runsvdir (with the runit init system)? What starts up whatver sv > script? > > Thanks, > > SteveT > > Steve Litt > January 2017 featured book: Troubleshooting: Just the Facts > http://www.troubleshooters.com/tjust -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Re: register runsvdir as subreaper
Hi! On Wed, Feb 1, 2017 at 12:49 AM, Jonathan de Boyne Pollard wrote: > You are talking to people well versed in the idea of chain-loading programs > for affecting process state. The answer here is to simply run runsvdir > through a chain-loading program that sets the process as a subreaper. > > You could write your own, or use the one that I wrote, packaged up, and > published. I called it "local-reaper". > > * http://jdebp.eu./Softwares/nosh/guide/local-reaper.html Very nice indeed. And as I see below you checked that it works with runsvdir. It seems local-reaper is part of nosh, for which you provide a deb package, but it is not included in Debian distribution. Is this correct? OK, so this could allow me to have a wrapper bash script which makes sure processes inside Docker container are gracefully closed when Docker container is stopped (see my other message to this mailing list), and then I run runsvdir as PID 2 with local reaper chained before it, so that any orphaned process is reaped by runsvdir. Because it seems one cannot simply set: trap "" SIGCHLD in a PID 1 bash script. It seems it does not work. Because otherwise one could just set SIGCHLD handler explicitly to SIG_IGN in PID 1 and leave to the kernel to handle the orphaned processes. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
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
register runsvdir as subreaper
Hi! I would like to ask if runsvdir could by default be defined as a subreaper on Linux. If it is already a PID 1, then there is no difference, but sometimes it is not. In that case when an orphan process happens under it, then it would be re-parented under the runsvdir, mimicking the behavior when runsvdir runs as a PID 1. runit is often used in Docker containers and sometimes you have a wrapper script which spawns runsvdir as a child. In that case runsvdir does not run as PID 1. I have found a similar patch for Debian, but which requested this feature on runsv. I think that might be misused for making process who demonize in fact stay under runsv. Or maybe that is a future feature of runit, not sure, but that can be discussion for some other thread. I would like to ask that something similar to that patch is done for runsvdir for now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833048 This would really make it easier to use runit inside Docker. A bit more about subreapers here: https://unix.stackexchange.com/questions/250153/what-is-a-subreaper-process Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m
