SIGHUP seems to cause initd to exit

[dpb587-pivotal]

BOSH team is trying to build stemcells in a concourse task and one of the steps is installing the runit package into a chroot'd filesystem. One of the postinst scripts the runit package executes is kill -s HUP 1. In our concourse task, this is causing our container to exit and we can't find a way to avoid that. In our Docker test environment we were able to trap '' HUP to ignore it, but that's not working here.

Is this intentional, and can you advise a workaround?

In our fly execute ..., it ends with the following, for what it's worth...

...snip...
Setting up python3-pycurl (7.19.3-0ubuntu3) ...
Setting up unattended-upgrades (0.82.1ubuntu2.4) ...
Setting up quota (4.01-3) ...
Setting up runit (2.1.1-6.2ubuntu3) ...
error streaming in: exit status 2. Output: tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

errored

We can also reproduce by doing fly execute with an empty container, hijacking in and running kill -s HUP 1 from the shell.

Thanks!

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/111811496.

[julz]

In docker the user process and the init process (pid 1) are the same. In garden - because we support multiple user processes in a container with their own lifecycle - we run our own init process in the container. This is why it is possible to trap the signal in your docker app but not in garden: in garden your app is not PID 1.

We could have initd (which is the small process we run as pid 1) trap SIGHUP easily enough, but this might be a bit of a sledgehammer solution. An alternative you could try would be to create your own mini-"container" with its own PID namespace inside the concourse container. You can do this quite easily just by running your application under unshare -p (e.g. if your process is runit you would change it to unshare -p runit). This way your process will be PID 1 in that process subtree, and will be able to catch the signal. This will require a privileged container (although it might be possible to do it in an unprivileged container if you also pass the --map-root-user -U flags).

[dpb587-pivotal]

We've one ahead and worked around the issue by using unshare -fp. It still seems a bit odd for a SIGHUP to cause the container to completely exit, but since we have the unshare workaround it doesn't really matter to our situation anymore. Thanks for the feedback and suggestion!

Feel free to close if you won't be making any initd changes around this.

[goonzoid]

Thanks. We're unlikely to address this any time soon, especially considering that we're now working on Guardian, so I'll close this.