[buildd-tools-devel] Bug#607844: Bug#607844: weird interaction between setsid and SIGTSTP
Kees Cook
kees at debian.org
Tue May 31 20:46:30 UTC 2011
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
More information about the Buildd-tools-devel
mailing list