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

[Kees Cook]

Hi Roger,

On Mon, May 30, 2011 at 07:41:16PM +0100, Roger Leigh wrote:
> 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).

It's still a problem yes, but arguably, it is a problem with Upstart. It
should only test controlling terminal logic if one is available.

> 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.

Right.

> 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.

I would tend to agree in this case.

-Kees

-- 
Kees Cook                                            @debian.org