RFE: Propagate signals from the user process into the chroot

[ifireball]

A typical scenario for using mock is to have some kind of an automation system (e.g. Jenkins) invoke mock to run things inside it in an isolated manner with fine control over the test environment.

An issue arises when an attempt is made to abort the test process (Either manually or due to an automated event such as a timeout). The automation system typically sends a signal to the processes it invoked to make them stop. With mock, the process the automation system sees is the consolekit wrapper that is used to run mock itself as root. When a signal is issue to it, the helper itself exits, but mock typically keeps on running as well as all the processes inside it.

I suggest a user-level executable will be added. That executable will establish some kind of a communication channel (E.g, a named pipe) and then invoke the root-level mock executable via consolekit. The root level executable would then listen on the communication channel for notifications about signals sent to the user-level process and propagate them to the processes it launched inside the chroot.

[xsuchy]

Or litlte easier - mock will respond to SIGKILL and will execute --orpanskill which will kill everything started by mock.

[plageat]

2 options came to mind:

• print pid of the running mock process somewhere, so that automation system can read and deal with it instead of consolehelper's pid
• there is a nice prctl.set_pdeathsig() https://pythonhosted.org/python-prctl/#prctl.set_pdeathsig, so we can catch when parent is killed (consolehelper is killed in our case as I understand). But it introduces an extra dependency of prctl, cause it is not in stdlib :( For this option I even have a little patch if interested

[ifireball]

@plageat - option #1 would require the automation system to have privileged access to the execution node other then being a member of the 'mock' group.

With option #2 I'm also not sure the signal can be routed across privilege boundaries.

[plageat]

I don't really know how it works like, but I think it shouldn't be a problem for such a system to parse mock's sdout/stderr or read output logs otherwise it is a question how it can work at all?)

As for the second, did not understand well about privilege boundaries. Just works fine whenever you can send SIGKILL to the mock process - it may be implemented to kill itself and all his child processes inside it

[Hojang2]

Hi, I'm just working on this issue. My solution would be to implement signal handler into the main mock thread. If handler would receive SIGTERM signal he would call orphansKill method to kill all processes related to mock. Does it fix your issue?