We're discussing detaching from the tty that startx(1) was executed on, not the tyy that the X11 server uses for its VT.
IE, you login to the shell on /dev/tty1, you run startx(1) there, and X11 starts on /dev/tty7. This is about disassociating with /dev/tty1. On Jul 26, 2011, at 1:42 PM, Lennart Poettering wrote: > On Tue, 26.07.11 16:34, Ray Strode ([email protected]) wrote: > >> The example serves to show that redirecting STDIN to /dev/null >> partially solves the same problem setsid partially solves.That problem >> is "detaching X clients from the tty startx was run on". >> >> Or is there another problem being solved, that you have in mind? > > I didn't really follow the discussion here, just wanted to note that > there's quite a bit of software that relies that the X server is the > controlling process of /dev/ttyX for the VT it is running on. > > ConsoleKit uses this to figure out the VT that a specific X server ended > up using without having to connect to it. In fact in pam_systemd there's > a similar hack to figure out the same information if it isn't specified > explicitly when setting up the session. (In CK it's the primary path to > determine this information, in pam_systemd just a fallback) > > What I am trying to say here basically: if you are planning to invoke > setsid() or detach from the controlling tty otherwise in the normal X > servers, then you'll break existing code. And I'd like to ask you not to > do that... > > But then again, I didn't really follow the discussion and maybe you are > discussing something compltely different. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
