Bug#45104: setsid() breakage
Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> the setsid() function does not behave correctly on the Hurd.
Indeed it does not. One of these is easy to fix; the other I have
some ideas about but Roland should certainly comment.
> First, it returns an unconditional 0 at succesful operation, instead the
> process group id.
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.
Index: sysdeps/mach/hurd/setsid.c
===================================================================
RCS file: /glibc/cvsfiles/libc/sysdeps/mach/hurd/setsid.c,v
retrieving revision 1.11
diff -u -r1.11 setsid.c
--- setsid.c 1997/05/26 22:24:25 1.11
+++ setsid.c 1999/09/16 03:19:22
@@ -1,4 +1,4 @@
-/* Copyright (C) 1993, 1994, 1995, 1997 Free Software Foundation, Inc.
+/* Copyright (C) 1993, 1994, 1995, 1997, 1999 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
@@ -51,7 +51,7 @@
#endif
}
- return 0;
+ return _hurd_pid;
}
weak_alias (__setsid, setsid)
> Secondly, and this is currently the main problem with screen, it does
> not disconnect properly from its controlling terminal. At least this
> is how I interpret the behaviour. First, screen: screen calls setsid(), and
> then does a read() on /dev/console while ignoring SIGTTIN. This leads to
> a failure EIO (which means that it still has /dev/console as ctty).
> Secondly, I tried to isolate a test case, which shows the errornous
> behaviour.
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.
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.
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.
Third issue; sysdeps/mach/hurd/sysd-stdio calls _hurd_port2fd in two
places. I'm don't know exactly what circumstances result in those
calls, but one or both of them should probably, at some time or other,
set O_IGNORE_CTTY also.
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. Another
option would be to have _hurd_port2fd *never* set the controlling
terminal, but have open() do an extra call to set it. (fopen needs to
set it too in the right cases, if it doesn't call open.)
But neither of these seem connected to the immediate problem, which I
confess I don't entirely understand. 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.
Reply to: