Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.unix.wizards Subject: Re: transferring processes under csh Keywords: job control Message-ID: <1272@mcgill-vision.UUCP> Date: 31 Aug 88 04:26:58 GMT References: <1074@imagine.PAWL.RPI.EDU> <1264@mcgill-vision.UUCP> <1988Aug27.162010.332@gpu.utcs.toronto.edu> Organization: McGill University, Montreal Lines: 123 In article <1988Aug27.162010.332@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > In article <1264@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >> In article <1074@imagine.PAWL.RPI.EDU>, hiebeler@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 , 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@larry.mcrcim.mcgill.edu