transferring processes under csh

[der Mouse]

In article <1988Aug27.162010.332 at gpu.utcs.toronto.edu>, woods at gpu.utcs.toronto.edu (Greg Woods) writes:
> In article <1264 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP (der Mouse) writes:
>> In article <1074 at imagine.PAWL.RPI.EDU>, hiebeler at pawl23.pawl.rpi.edu (David Hiebeler) writes:
>>> Does anyone know of a way to transfer processes between different
>>> incantations of csh?
>>> [Suppose I put a job in the background on one terminal.]
>>> Is there any way at all that I can, _from another terminal_, bring
>>> that job into the foreground _on the new terminal_?
>> Insofar as this is possible, it's not exceptionally useful, and
>> insofar as it's useful, it's not possible.
> I would say, that if it was available, it would be exceptionally
> useful.

Yes.  But what I meant was to say that the easy part isn't the useful
part and vice versa.

>> [Mouse mumblings about why this gets difficult]
> I think it would be wrong to have the kernel sneak in and change a
> stopped process's environment list.

Yes.  I also maintain it's impossible, in general.

> Perhaps a device driver (/dev/environ) could be used by a process,
> upon SIGCONT, to read a new environment from.

An interesting idea.  It might work out so it could solve some of the
knottier problems this causes.  But this means carrying a bunch more
data around with each process: stuff waiting to be read from
/dev/environ.

> I think it is necessary for the kernel to re-wire stdin, stdout, and
> stderr for the child process to the new tty, and possibly to somehow
> make the child a member of the new ttygroup.

Not stdin/stdout/stderr per se, but rather any file descriptors which
point to the old control terminal.

Changing the child's process group ID is trivial for the kernel; it's a
couple of assignment statements.

> Maybe this will be implicit when the child ppid is changed in the
> process table?

Not so, at least not on Berkeley.

>> There are also some difficult questions: what does the old parent
>> process see?  An exited child?  Killed by some special signal
>> number?  Child vanishes without dying (the truth, but highly
>> confusing to existing programs)?
> The old parent should see an exited child, hopefully with a new exit
> value from sysexits.h that would reveal its fate.

I don't like this idea.  Why?  Because sysexits.h is a convention used
by user-level programs with one another; the kernel knows nothing of
it.  (It's not <sys/exits.h>, after all.)  I believe the kernel
shouldn't know anything about exit codes; it currently doesn't even
know the difference between exit(0) and exit(non-zero).

If I were to do this, I think the child would disappear.  I would
prefer to have the kernel tell the truth at the price of a small amount
of compatibility rather than tell a lie that will have to be supported
in perpetuity in the name of compatibility.  Much better to have only
one flag day rather than two.

> Remember also that SIGCHLD only means that the child's status has
> changed.

I wasn't arguing for a change in SIGCHLD semantics, or at least I
didn't think I was, though it may turn out that a SIGCHLD must be sent
when a child disappears.

> In most cases I'd imagine that the parent would already be dead
> anyway.  Maybe only foster children can be allowed to be adopted by a
> new parent.

The commonest case, in my expectation, would be the adoption of a job
from another shell, without the other shell's dying.  As when a
consultant takes over a job from a user to look at it.  If the parent
is already dead, then the process is a child of init and is probably
gone anyway.

> Of course children can only be adopted by a parent with the same real
> or effective UID, or by a superuser process.

I'm not sure this is correct.  I would argue that the old and new
parents must have the same UID, regardless of the UID of the child.
This allows two logins of the same user to transfer a setuid process
back and forth between them.  But this has security implications for
the setuid process; perhaps all three processes would have to have the
same UID.

Of course, a root process is allowed to adopt anything it feels like,
regardless of UIDs.  (Though I might make an exception for process IDs
0, 1, and 2.)

> Should this even be allowed by the superuser, since the superuser can
> always su?

Yes, it should be allowed.  Why?  First for poslfit: there is currently
nothing that the kernel allows a user to do but doesn't allow a
superuser to do.  (That I can think of.  If there is, please tell me so
I can fix it.)  Second because there's no tool currently available to
give root a shell running under an arbitrary UID.  (Generally
available, that is; I have one I wrote a while back.  Note that the UID
is not necessarily present in /etc/passwd.)  Third because that's how I
want it :-).

> If the orphan child is a process group leader, do you adopt the whole
> family?  I think so.

I would prefer to have two calls, or two variants of one call: one to
adopt a single process and one to adopt a whole process group.

> How about the ability to adopt (migrate) jobs from another machine on
> a homogeneous network?

Pipe dreams may apply at the window down the corridor.  Until you have
an operating system that makes it all look homogenous (ie, like one big
cpu), I won't worry about it.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu