pid namespace bug ?

[Sukadev Bhattiprolu]

Ferenc Wagner [wferi at niif.hu] wrote:
| > So to terminate a cinit from parent namespace you need SIGKILL. But other
| > signals will be delivered to cinit only if it has a handler.
| 
| Thanks for clarifying.  How does the above apply to signalfds?  Will
| those deliver the signals which would otherwise been ignored by cinit,
| having no handler installed?

Yes, if the signal is blocked, the signal will still be queued regardless
of sender's namespace[1]. In this case the blocked+pending signal will be
available via the signalfd() until the signal is unblocked.

If the signal is not blocked and the handler is either SIG_DFL or
SIG_IGN, the signal is not queued and will not be available via signalfd.

[1] Blocked signals have some special cases even without signalfd() - If
the signal is queued and later unblocked and the handler is SIG_DFL/SIG_IGN,
the signal will be silently discarded (regardless of sender's namespace).

If the user specifies a handler before unblocking the signal, the signal
will be delivered (regardless of sender's namespace)

| 
| >| They are used for communication (job control) with the container running
| >| the job.  Such batch jobs are typically run under the supervision of
| >| some kind of "shepherd" process, which acts as "init" for the job
| >| environment; in my case it's the container-init.  It's the reaper or
| >| possible orphaned processes and the same time it communicates with the
| >| job scheduler (outside of the container) via signals.
| >
| > So can this job scheduler install handlers for SIGINT/SIGTERM/SIGQUIT ?
| 
| The scheduler is outside of the container, so I suppose you mean the
| shepherd process, which is the container init.  Yes, it already has
| handlers for each signal it's interested in, so according to the above,
| everything should work as expected (once we get the signals forwarded to
| it).

Yes, I meant the shepherd process.

| 
| >| So I'd consider at least some kernel complexity necessary for Linux
| >| containers becoming a viable tool for batch job segregation.
| >
| > Yes, it is annoying that we can't CTRL-C a cinit running /bin/sleep, but
| > this behavior should not be too limiting to a more functional cinit.
| 
| Indeed.  I misunderstood you on first read.
| 
| > I had submitted a verbose man page patch for kill(2) to describe these
| > semantics. but following para in the notes section of kill(2) does
| > allude to this behavior:
| >
| >        The only signals that can be sent to process ID 1, the init
| >        process, are those for which init has explicitly installed signal
| >        handlers.  This is done to assure the system is not brought down
| >        accidentally.
| 
| I even read that paragraph recently.  I didn't think it would apply,
| though, as I was trying to kill cinit in the outer namespace, where it
| had a generic PID, not 1.  Your effort to expand the man page of kill(2)
| is most appreciated, I hope it will land soon!

I do see now that it is ambigous and incomplete - the special handling applies
to a process if it has a pid == 1 in *any* namespace.

Second it does not mention that SIGKILL/SIGSTOP are the only reliable signals
to a container-init from parent namespace.

Will submit a patch for the man page change.

Thanks,

Sukadev