[buildd-tools-devel] Bug#607844: Bug#607844: weird interaction between setsid and SIGTSTP

[Roger Leigh]

On Wed, Dec 22, 2010 at 02:17:45PM -0800, Kees Cook wrote:
> While trying to build "upstart" in Ubuntu using the latest sbuild, one of
> the unit tests failed. This was reduced to a test of "raise(SIGTSTP)",
> which wasn't actually stopping the process. In tracking this down, I
> isolated it as far as setting SETSID to 1 during the Sbuild::Build phase.
> 
> Attached is "wstopped.c" and "sbuild-poc" which tries to isolate the
> problem. With SETSID=0, I get the expected behavior; the process waits for
> SIGCONT:
> 
> # perl /tmp/sbuild-poc /tmp/wstopped 0
> ok
> 
> With SETSID=1 (last cmdline option), the process does not wait for SIGCONT:
> 
> # perl /tmp/sbuild-poc /tmp/wstopped 1
> waitid: No child processes
> 
> The bulk of wstopped.c is the creation of IPC pipes to make sure the child
> has started and the parent can wait on it.
> 
> Very weird. Do you have any idea what is going on here?

Hi Kees,

I was wondering whether or not this is still an issue for upstart?

As far as I understand, the build is failing because we run
dpkg-buildpackage without a controlling TTY.  This has been the
historical behaviour of sbuild (though for a short while the
behaviour was removed).

From the sbuild POV, the question is whether or not this is
appropriate, and if we should continue to do this.  However, while
sbuild explicitly calls setsid, one consideration is that when
run by buildd, buildd is itself already detached from its CTTY
when it dæmonises, as a result any change in sbuild would only
have an effect when run interactively.

If we were to alter sbuild's behaviour, we would have to create
a PTY, run dpkg-buildpackage on the slave side and have sbuild
record the build log from the master side.

On the other hand, if upstart requires a CTTY for its tests, it
would make sense for the test code to create a dedicated PTY for
its tests to ensure that the tests will always run connected to
a terminal.  A simple openpty(3) would be sufficient if you
dup() stdin/out/err for the child after fork so that the test
runs on the PTY slave.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110530/0ab054c7/attachment.pgp>