Re: register runsvdir as subreaper

[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
> >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

[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

[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 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

[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 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

[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
> >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

[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 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

[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 *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

[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 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

[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 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

[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

[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 complicated (you're need to wrap runsv), but this is not
what the OP asked for.

--
 Laurent

Re: register runsvdir as subreaper

[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 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

[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 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.