On Thu, Mar 30, 2017 at 10:15:02AM +0300, Dmitry Bogatov wrote:
> > > > it would be great to be able to use runit to supervise processes
> > > > running in
> > > > vserver guests.
> > > >
> > > > Using a kludge, this is already sort of possible; see
> > > > http://linux-vserver.org/Running_runit-supervised_services_inside_a_vserver
> > > >
> > > > Essentially, the only addition needed is to do something like
> > > >
> > > > xid_t xid = vc_get_task_xid(child);
> > > > vc_ctx_kill(xid, child, signal);
> > > >
> > > > instead of just kill(), provided vserver support is enabled in runit
> > > > and the
> > > > kernel.
> > >
> > > control: tags -1 +moreinfo
> > >
> > > Is there still someone who wish to make this change? If there, I still
> > > oppose of introducing dependency. Even optional. Especially optional.
> >
> > I suppose introducing a new dependency could be avoided thusly: in runsvdir,
> > instead of invoking runsv for each directory, check whether the directory
> > contains a file called runsv, and if it does, launch that instead of runsv.
> > This would be totally backwards compatible.
>
> Nice idea. But why can not you just invoke 'exec run-in-my-namespace
> /sbin/program? in 'run' script?
Because vanilla runsv would be unable to send its child signals if the child
runs in a different namespace/security context.
> > This change would allow people to use runsv replacements that expose the
> > same interface to runsvdir(8) and sv(8) but for example support managing
> > children that run in a different pid namespace.
Andras
--
*Real* real programmers use 'bzcat > a.out' 'cause you can type faster.
