Re: Reparenting processes?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Waking up this thread from about a month ago....

>>> [...process reparenting...]
>> [...auto-reparenting to init...]
> [...] most of the code I want already exists.

> The pieces that don't are things like dealing with control ttys and
> sessions [...]

Yesterday and today, I picked this up and started to write code.

I've got most of it, I think.  But there's a piece that prompts me to
write back here.

Dealing with most of it is easy.  The reparenting proper is already
done, both for ptrace and for orphans moving to init.  Switching the
process's pgrp to a new session isn't that hard, and that automatically
switches controlling tty (since a process's ctty is obtained by chasing
through p->p_pgrp->pg_session->s_tty{,v}p).

The hard part is file descriptors.  Most processes typically have a few
file descriptors (usually 0, 1, 2) open on their controlling tty.  But
they aren't open on /dev/tty; they're open on /dev/tty01, /dev/ttya,
/dev/ttyE2, /dev/ttyp4, or whatever, so just changing ctty won't move
them.

Leaving them connected to the old tty, which is no longer the process's
session's ctty, seems wrong; if nothing else, generated output will go
to the wrong tty (or cause an "incorrect" SIGTTOU).  I can, perhaps,
drill down through the data structures and switch them to the new ctty,
but then there's a problem: what if a fd on the old ctty was opened not
because it was the login tty inherited from however the login session
was created, but was opened explicitly (either by the shell or by the
process)?  (The case where the new session has no ctty I'm willing to
EINVAL on; my movating use cases always have cttys.)

This makes me wonder if perhaps login sessions should have their
stdin/stdout/stderr set up on /dev/tty instead of the actual ctty
device.  But if that's done, will the `real' ctty device even be open?
I think /dev/tty doesn't keep an open on the underlying tty device, nor
can I see any easy way for it to do so, since /dev/tty itself doesn't
get a close call until no process in the whole system, not just no
process with that ctty, has a descriptor open on /dev/tty.

I'm not convinced there is a single right answer.  I'm writing to ask
if anyone here has any thoughts to share on these issues.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B