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
>
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
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
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
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
>
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
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
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
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
If your question was about the mechanism of wrapping runsv:
mv /bin/runsv /bin/runsv.real
cat > /bin/runsv <
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
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
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
13 matches
Mail list logo