Re: register runsvdir as subreaper
On Thu, 02 Feb 2017 19:30:17 + "Laurent Bercot" wrote: > >There's also the possible case of having this for getty/login > >session. So any process spawned from there won't be reparented to > >PID1 but to e.g. the session's supervisor; That can include things > >such as pulseaudio, settings daemon, dbus, window manager, etc > > Those are more examples of what you *can* do, with no precise reason > why you *should*. http://e.lvme.me/u33yl35.jpg > > > >Also besides the visually pleasing pstree, it means one can - thanks > >to a finish script - ensure that upon logout everything gets killed > >before a new getty is respawned. If that ability floats your boat, there's a perfectly wonderful init system that does that: Systemd. As far as the visually pleasing pstree, I'd rather have a messy pstree and simple, robust architecture than an aesthetically beautiful pstree and entangled, messy architecture. > > How would you do that? Unless the subreaper comes with yet another > system call to genocide all its children, you still need some > mechanism to atomically send a signal to everything - which means you > want to have everything into the same process group (which is > unlikely if you have an interactive session), or you need cgroups. Hey, I've heard of this great new init system that's all about cgroups! > > And even if you can, that still doesn't mean you should. Nohup is a > thing. I use it all the time, and half the time pipe its output to /dev/null. I doublefork a lot too. When I make a shellscript or design software, I never depend on the getty or terminal emulator's close closing my software. If I want it closed, I make it close itself. > People may want to leave background processes running after > they log off. Yes! Talk to any tmux user about this. I'd rather have a few orphans and zombies hanging around than foreclose the user's ability to start working from one computer and finish working at one 30 miles away, having logged out of the first one. I don't understand this desire some folks have to implement the marketing points of systemd. Visually pleasing pstree? Logging out kills all processes started during that login? What next, socket activation? Keyless remote with magnesium paddle shifter? In the features vs simplicity tradeoff, why do so few value simplicity? Runit, which I use every day, is so simple I could create a clone of it after reviewing djb's supervisor backgrounding code for about 10 minutes, and Gerrit, this isn't an insult to runit, it's a huge compliment. Runit's enough for me, but for the person wanting more USEFUL features and a guarantee against having an incommunicative, childless PID1, there's s6. And although not on-topic for a supervisor mailing list, Epoch provides wonderful init features in a very simple package. Every time I hear people wanting inits to do more, my question is "why does it have to be done in the init?" Whatever you want to do, there are a million ways to do it, so it's not necessarily the responsibility of already-written, highly functioning software. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: register runsvdir as subreaper
Laurent Bercot: if runsvdir uses PATH resolution to find runsv prog[0] ="runsv"; prog[1] =name; prog[2] =0; ... pathexec_run(*prog, prog, (const char* const*)environ);
Re: register runsvdir as subreaper
Laurent Bercot: You want runsvdir to be your reaper, so you'd just run "local-reaper runsvdir scandir" instead of "runsvdir scandir". Actually you'd run > local-reaper true runsvdir scandir
Re: register runsvdir as subreaper
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. Don't worry about that. When run from an unshared PID namespace, the reboot() system call is diverted by the Linux kernel and does not really reboot, it just kills the pid 1 in that namespace (so it will stop your 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. Processes are not a scarce resource. Running more processes on a Unix system is not a problem - Unix systems were _designed for that_. What are scarce resources are RAM and CPU, which runit, s6, and other supervision systems, use very sparingly. If you use runit as pid 1 instead of trying to have runsvdir be pid 1, you will make your life easier and not notice the difference. (You should still check s6-overlay as John advises. You would then get the best of both worlds, with s6-svscan (the equivalent of runsvdir) running as pid 1. ;)) 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? No, because you need stage 3 to clean up everything at shutdown time. -- Laurent
Re: register runsvdir as subreaper
On 02/02/2017 03:29 PM, Mitar wrote: 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 I'm going to really recommend checking out the s6-overlay, I think it will do everything you're talking about out-of-the-box. No need to customize the Docker stop signal, it handles gracefully shutting down services, reaping orphaned processes, and so on. It's really useful and will probably save you a lot of time. https://github.com/just-containers/s6-overlay -John Regan
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
On Thu, 02 Feb 2017 19:30:17 + "Laurent Bercot" wrote: > >There's also the possible case of having this for getty/login > >session. So any process spawned from there won't be reparented to > >PID1 but to e.g. the session's supervisor; That can include things > >such as pulseaudio, settings daemon, dbus, window manager, etc > > Those are more examples of what you *can* do, with no precise reason > why you *should*. http://e.lvme.me/u33yl35.jpg > > > >Also besides the visually pleasing pstree, it means one can - thanks > >to a finish script - ensure that upon logout everything gets killed > >before a new getty is respawned. > > How would you do that? Unless the subreaper comes with yet another > system call to genocide all its children, you still need some > mechanism to atomically send a signal to everything - which means you > want to have everything into the same process group (which is > unlikely if you have an interactive session), or you need cgroups. No atomic signal sending syscall no, so it is imperfect yes, but one can find children and send a signal to them. At least in my case, it helps cleaning things that would otherwise stay around while I don't wish for them to. > And even if you can, that still doesn't mean you should. Nohup is a > thing. People may want to leave background processes running after > they log off. The current mechanism of SIGHUPping everything when the > session ends works, and can be ignored when needed - sounds perfect > to me. Sure, and I wouldn't do that for everything, but for gettys (where graphical sessions will be started) & my use case, I find it pretty nice. > >So now you're not solving the original need of making a nice > >pstree; > > I question the importance of that "need" when balanced against the > cost of system lock-in - this cost is invisible, which is why most > people happily ignore it, but it's there nonetheless. > > > >Also, it was needed for containers (or pid namespace that is), where > >you > >certainly don't want to see orphans disappear from the container/pid > >namespace as they get reparented to the "main" PID1. > > Oh, definitely, but making the "new" pid1 a reaper could just be > done by the kernel at unshare time, without a separate entry point. > > > >Having the ability to make other processes subreapers as well/without > >the need to be PID1 in a new pid ns can be nice. > > I guess this is just a matter of opinion at this point, but I > disagree - > I think this ability does more harm than good. > > > >As much as you may dislike it, my s6-supervise processes are > >subreapers, svscan's children can only be supervisors, anything else > >will remain under its supervisor, and I like it :) > > You can only do that because s6-supervise correctly handles children > it does not know it has. Be thankful the code is liberal in what it > accepts, even when I disagree with the idea. :P Of course that's due to s6-supervise reaping unknown zombies, and I am thankful it works as it does yes :)
Re: register runsvdir as subreaper
Or put your script as /usr/local/bin/runsv (assuming /usr/local/bin is in your PATH ofc) so the original runsv is left untouched, which is nice (I feel), and certainly better when using a package manager. Indeed, if runsvdir uses PATH resolution to find runsv, it's easier and better to override runsv via PATH. However, you should not assume that an executable in a package always uses PATH resolution to find other executables in the same package. To ensure reproducible behaviour and independence from the environment, it is perfectly valid for an executable to hardcode paths to its companion executables, in which case you have to replace the binary if you want to wrap it. -- Laurent
Re: register runsvdir as subreaper
There's also the possible case of having this for getty/login session. So any process spawned from there won't be reparented to PID1 but to e.g. the session's supervisor; That can include things such as pulseaudio, settings daemon, dbus, window manager, etc Those are more examples of what you *can* do, with no precise reason why you *should*. http://e.lvme.me/u33yl35.jpg Also besides the visually pleasing pstree, it means one can - thanks to a finish script - ensure that upon logout everything gets killed before a new getty is respawned. How would you do that? Unless the subreaper comes with yet another system call to genocide all its children, you still need some mechanism to atomically send a signal to everything - which means you want to have everything into the same process group (which is unlikely if you have an interactive session), or you need cgroups. And even if you can, that still doesn't mean you should. Nohup is a thing. People may want to leave background processes running after they log off. The current mechanism of SIGHUPping everything when the session ends works, and can be ignored when needed - sounds perfect to me. So now you're not solving the original need of making a nice pstree; I question the importance of that "need" when balanced against the cost of system lock-in - this cost is invisible, which is why most people happily ignore it, but it's there nonetheless. Also, it was needed for containers (or pid namespace that is), where you certainly don't want to see orphans disappear from the container/pid namespace as they get reparented to the "main" PID1. Oh, definitely, but making the "new" pid1 a reaper could just be done by the kernel at unshare time, without a separate entry point. Having the ability to make other processes subreapers as well/without the need to be PID1 in a new pid ns can be nice. I guess this is just a matter of opinion at this point, but I disagree - I think this ability does more harm than good. As much as you may dislike it, my s6-supervise processes are subreapers, svscan's children can only be supervisors, anything else will remain under its supervisor, and I like it :) You can only do that because s6-supervise correctly handles children it does not know it has. Be thankful the code is liberal in what it accepts, even when I disagree with the idea. :P -- Laurent
Re: register runsvdir as subreaper
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 > > >
Re: register runsvdir as subreaper
On Thu, 02 Feb 2017 16:50:03 + "Laurent Bercot" wrote: > If your question was about the mechanism of wrapping runsv: > > mv /bin/runsv /bin/runsv.real > cat > /bin/runsv < #!/bin/sh > exec local-reaper /bin/runsv.real "$@" > EOF > chmod 755 /bin/runsv Or put your script as /usr/local/bin/runsv (assuming /usr/local/bin is in your PATH ofc) so the original runsv is left untouched, which is nice (I feel), and certainly better when using a package manager. > Of course, the best solution is still to do nothing and forget that > subreapers are even a thing. (And also to switch to s6. :P) > > -- > Laurent >
Re: register runsvdir as subreaper
On Wed, 01 Feb 2017 16:48:15 + "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 There's also the possible case of having this for getty/login session. So any process spawned from there won't be reparented to PID1 but to e.g. the session's supervisor; That can include things such as pulseaudio, settings daemon, dbus, window manager, etc Also besides the visually pleasing pstree, it means one can - thanks to a finish script - ensure that upon logout everything gets killed before a new getty is respawned. > place. Is that impossible? Use process groups to identify what service > the orphans were originally spawned from: if needed, you can send a So now you're not solving the original need of making a nice pstree; Not to mention in the case mention above there will be new process groups created, so that's not applicable. > signal to the whole process group, and it will reach all the processes > in the service, including orphans. > Reparenting orphans to anything else than the default is a backwards > way to solve a nonexistent problem. Except maybe for people who want a clean process tree as you originally mentioned. Also, it was needed for containers (or pid namespace that is), where you certainly don't want to see orphans disappear from the container/pid namespace as they get reparented to the "main" PID1. For PID1 inside a new pid ns to be a PID1, it needs to be a subreaper. Having the ability to make other processes subreapers as well/without the need to be PID1 in a new pid ns can be nice. As much as you may dislike it, my s6-supervise processes are subreapers, svscan's children can only be supervisors, anything else will remain under its supervisor, and I like it :) > Note that s6 will work in containers, for instance with s6-overlay > as John mentioned. Unlike runit, it also allows you to customize what > it does on receipt of a SIGTERM. > > -- > Laurent >
Re: register runsvdir as subreaper
If your question was about the mechanism of wrapping runsv: mv /bin/runsv /bin/runsv.real cat > /bin/runsv <
Re: register runsvdir as subreaper
Except in this case, runsvdir executes runsv, so you have to tell runsvdir to chain-load. You want runsvdir to be your reaper, so you'd just run "local-reaper runsvdir scandir" instead of "runsvdir scandir". If you wanted runsv to be your reaper instead, it would indeed be somewhat more complicated (you're need to wrap runsv), but this is not what the OP asked for. -- Laurent
Re: register runsvdir as subreaper
On Thu, Feb 2, 2017 at 3:07 AM, Jonathan de Boyne Pollard wrote: > Roger Pate: >> (And how should we apply chain-loading local-reaper to runsv?) > How to wrap a program inside something else that does additional stuff then > exec()s the original program *is* a solved problem on Unices and Linux, you > know. (-: Except in this case, runsvdir executes runsv, so you have to tell runsvdir to chain-load. How would you do that? (Without modifying runsvdir? Or is modification required?) Forgive me if I've missed something obvious.
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
Re: register runsvdir as subreaper
Roger Pate: Simple, but you do point out in local-reaper's docs, "One cannot just apply this willy-nilly." :P One can apply it to runsvdir. I checked. It waits for arbitrary children, and does not get confused by children that it did not spawn turning up. Roger Pate: (And how should we apply chain-loading local-reaper to runsv?) How to wrap a program inside something else that does additional stuff then exec()s the original program *is* a solved problem on Unices and Linux, you know. (-:
Re: register runsvdir as subreaper
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
Re: register runsvdir as subreaper
On Mon, 30 Jan 2017 09:38:38 -0800 Mitar wrote: > 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. Hi Mitar, As far as I know, runsvdir from the runit project is never PID1: It's called from an sv that's forked by PID1. On my computer, the program called runit is PID1, and its child is runsvdir. The runit program reaps zombies. You might want to do a ps axjf | less on your Docker to see what's really acting as PID1, and see if you can reap zombies there. Check out the PID1 code at the bottom of http://ewontfix.com/14/ . Note the following code: for (;;) wait(&status); The preceding reaps zombies. Perhaps you could start up runsvdir with that. But wait,there's more. The folks at Suckless Tools wrote a better version of the ewontfix.com code that also handles signals: http://core.suckless.org/sinit http://git.suckless.org/sinit/ If you have control over the Docker container, and if you're initting via runit, you almost certainly have a distinct PID1 that does little but reap zombies, listen for signals, and fork the sv system which of course spawns runsvdir. So if I understand your request, it should be doable via the existing PID1, or via a PID1 you substitute or add code to. SteveT Steve Litt January 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
Re: register runsvdir as subreaper
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.
Re: register runsvdir as subreaper
Unlike runit, it also allows you to customize what it does on receipt of a SIGTERM. Clarification: runit allows you to customize the action of a signal sent to _a service_. It does not allow you to customize the action of a signal sent to _the root of the supervision tree_ (runsvdir). -- Laurent
Re: register runsvdir as subreaper
There is no objective basis for such a claim, this not actually being a minimal requirement of process #1. Welcome to the future. Your service manager does not have to be process #1. Your interactive logins are ordinary services controlled by your service manager. Orphaned child processes are reparented to your service manager or to some other process that is even closer to them. I'm still waiting for someone to show me tangible benefits to declaring subreapers. An orphan child has nobody to report its exit code to. Nobody cares *how* exactly an orphan dies. A reaper, be it pid 1 or something else, cannot do anything with the wstat it gets from all the orphans it reaps; it can only lay zombies to rest, and that's it. The only process that can benefit from a child's exit code is the child's direct parent, because it knows how to interpret it, and *no* other process does. As far as I can see, it does not matter in the slightest who's in charge of orphans: it's purely a convention. And so, subreapers are a perfectly useless addition to Unix, with the dubious benefits of being cool and new, and the proven drawbacks of being non-standard, harming portability and adding needless complexity to code that falls into the trap of using them. 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. Is that impossible? Use process groups to identify what service the orphans were originally spawned from: if needed, you can send a signal to the whole process group, and it will reach all the processes in the service, including orphans. Reparenting orphans to anything else than the default is a backwards way to solve a nonexistent problem. Note that s6 will work in containers, for instance with s6-overlay as John mentioned. Unlike runit, it also allows you to customize what it does on receipt of a SIGTERM. -- Laurent
Re: register runsvdir as subreaper
On Wed, Feb 1, 2017 at 3:49 AM, Jonathan de Boyne Pollard wrote: > Mitar: > >> I would like to ask if runsvdir could by default be defined as a subreaper >> on Linux. > > 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. Simple, but you do point out in local-reaper's docs, "One cannot just apply this willy-nilly." :P > 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. However, I think runsv is a better place to apply this than runsvdir. (And how should we apply chain-loading local-reaper to runsv?) For the use case of process-tree-as-admin-tool, knowing which service spawned those processes is much more useful than guessing from among many.
Re: register runsvdir as subreaper
On 01/30/2017 11:38 AM, Mitar wrote: 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 If you're looking to supervise processes inside containers, I'd recommend checking out s6-overlay[1] - it's s6 + a collection of scripts, meant to be used within containers for any Linux distro. It handles reaping processes, logging, log rotation - it's a swiss army knife. Full disclosure, I'm a member of the project :) [1]: https://github.com/just-containers/s6-overlay
Re: register runsvdir as subreaper
Mitar: I would like to ask if runsvdir could by default be defined as a subreaper on Linux. 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
Re: register runsvdir as subreaper
Kamil Cholewiński: Reaping orphaned children should be the duty of PID 1. * http://unix.stackexchange.com/a/197472/5132 * http://unix.stackexchange.com/a/177361/5132 There is no objective basis for such a claim, this not actually being a minimal requirement of process #1. Welcome to the future. Your service manager does not have to be process #1. Your interactive logins are ordinary services controlled by your service manager. Orphaned child processes are reparented to your service manager or to some other process that is even closer to them.
Re: register runsvdir as subreaper
> 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. Reaping orphaned children should be the duty of PID 1. Adding Linux-specific hacks to runit (or, for that matter, ANY other piece of software) feels very wrong, especially since there's a way to solve your problem correctly, without changing a single line in runit. > 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. Read up on execve(2), and the exec builtin in the shell. Also look up unit9/base[1][2], which is Debian + runit, done as correctly as possible, with the absolutely minimal possible amount of cruft. (Disclaimer: I'm the author.) [1]: https://hub.docker.com/r/unit9/base/ [2]: https://github.com/unit9/docklabs/tree/master/base <3,K. On Mon, 30 Jan 2017, Mitar wrote: > 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
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
