Re: register runsvdir as subreaper

2017-02-03 Thread Steve Litt
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 >

Re: register runsvdir as subreaper

2017-02-02 Thread Jonathan de Boyne Pollard
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

2017-02-02 Thread Laurent Bercot
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

Re: register runsvdir as subreaper

2017-02-02 Thread John Regan
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

Re: register runsvdir as subreaper

2017-02-02 Thread Olivier Brunel
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 >

Re: register runsvdir as subreaper

2017-02-02 Thread Laurent Bercot
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

Re: register runsvdir as subreaper

2017-02-02 Thread Laurent Bercot
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

Re: register runsvdir as subreaper

2017-02-02 Thread Olivier Brunel
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

Re: register runsvdir as subreaper

2017-02-02 Thread Olivier Brunel
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

Re: register runsvdir as subreaper

2017-02-02 Thread Laurent Bercot
If your question was about the mechanism of wrapping runsv: mv /bin/runsv /bin/runsv.real cat > /bin/runsv <

Re: register runsvdir as subreaper

2017-02-02 Thread Laurent Bercot
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

Re: register runsvdir as subreaper

2017-02-02 Thread Mitar
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

Re: register runsvdir as subreaper

2017-02-02 Thread Jonathan de Boyne Pollard
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

Re: register runsvdir as subreaper

2017-02-01 Thread Steve Litt
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

Re: register runsvdir as subreaper

2017-02-01 Thread Steve Litt
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

Re: register runsvdir as subreaper

2017-02-01 Thread Roger Pate
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

Re: register runsvdir as subreaper

2017-02-01 Thread John Regan
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

Re: register runsvdir as subreaper

2017-02-01 Thread Jonathan de Boyne Pollard
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