Bug#45104: setsid() breakage
> That's the easy one. Here's a patch. If it works, submit it to
> drepper.
>
> 1999-09-15 Thomas Bushnell, BSG <tb@mit.edu>
>
> * sysdeps/mach/hurd/setsid.c (__setsid): Return correct value upon
> success.
I have already fixed this, and will check it in shortly.
> I believe the problem here is more tough to solve correctly. Roland,
> please comment on the three issues I've noted, and anything else you
> can offer.
I think that you are mistaken about some of the behavior and also are
confusing O_IGNORE_CTTY with O_NOCTTY, so your three issues are in fact red
herrings and your fourth comment that there is an unrelated bug Marcus is
seeing that remains to be debugged is quite right (but, alas, does not shed
any new light on the situation).
O_IGNORE_CTTY is a nonstandard Hurd extension (your suggestion, in fact).
It has the meaning of completely ignoring the ctty status, so that you do
normal non-ctty io to the port, regardless of whether it's your ctty or not.
POSIX.1 has no way to request this functionality.
O_NOCTTY is the flag specified by POSIX.1 for `open'. POSIX.1 specifies
that if you do not have a controlling terminal and you open a terminal file
with O_NOCTTY, it will definitely not become your controlling terminal as a
result. If you have no controlling terminal and open a terminal file
without O_NOCTTY, POSIX.1 leaves it implementation-defined whether or not
that terminal becomes your controlling terminal as a result. In the Hurd,
as in BSD, we specify that `open' *never* changes the controlling terminal
regardless of O_NOCTTY; and, in fact, O_NOCTTY is defined to zero so that
there is no such flag to check at all.
In the Hurd (and BSD) the only way to set a process's controlling terminal
(other than by inheritance in fork or exec) is with the TIOCSTTY ioctl.
> One bug, probably not connected: If a program with no controlling
> terminal execs, but which has a terminal open, then the new image will
> acquire a controlling terminal. This is wrong. The call to
> _hurd_port2fd inside dtable.c:init_dtable should set the O_IGNORE_CTTY
> flag to prevent the aquisition of a controlling terminal as a side
> effect of exec.
You are clearly confused about how those functions work. _hurd_port2fd has
nothing to do with choosing the controlling terminal; it simply checks
(unless given O_IGNORE_CTTY) if the port is in fact to the controlling
terminal device already associated with process. The `ctty' io ports do
not control what is the ctty, the process's CTTYID port controls that.
> Second bug (documentation): In <hurd/fd.h> the documentation for
> hurd_fd.ctty gets port and ctty backwards. `port' is always a vanilla
> port; `ctty' is sometimes a magical port.
Yes, I was briefly confused about that myself; that's no doubt because it
used to be reversed in a previous incarnation of the implementation.
> In fact, tracking this is a real pain. Perhaps we should set
> O_IGNORE_CTTY to zero, and have _hurd_port2fd *never* set the
> controlling terminal, and have an explicit call to set it.
You clearly have O_NOCTTY in mind. O_NOCTTY is zero, and there is an
explicit call to set it (ioctl with TIOCSCTTY); BSD is the same.
> But neither of these seem connected to the immediate problem, which I
> confess I don't entirely understand.
Alas, you seem to have misplaced the understanding even of how it is
supposed to work, that I'm sure you had at one time in the past.
> Debugging would be useful; my Hurd partition crashed (as noted
> previously) so until I restore it, I won't be able to debug it directly
> myself.
Thank you for playing. Please come again soon.
Reply to: