mouse@mcgill-vision.UUCP (der Mouse) (08/26/88)
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_? First: as far as I know, there is no existing mechanism which would allow this. Insofar as this is possible, it's not exceptionally useful, and insofar as it's useful, it's not possible. It would be relatively easy (easy relative to the other points I'll bring up, that is) to hack some way into the kernel to transfer ownership of the job from the one shell to the other. It would even be possible to hotwire its file descriptors so that the ones that used to point to the old terminal now point to the new terminal. (Is this enough? You tell me.) But, and I suspect this is the reason this capability isn't available right now, this isn't good enough. Suppose the job is an editor - vi, say. The terminal will in general be a different type, implying that all vi's knowlege about the terminal must be reworked. Unfortunately, there's no way for vi to find out what the current terminal type is! Or rather, no practical way. It would require that the shell rewrite the environment in the vi process. And a mechanism to signal vi that it has to reread the environment. And nontrivial code in vi to handle this change. And in every other screen-oriented program. And rewriting the environment is, in general, not even possible without kernel modifications so extensive as to amount to half of a rewrite. If you're running 4.3 and you just want it to work for dumb programs, I can put it together for you within a day or two, I believe. But the last little bit, the part that would make it really useful, is well-nigh hopeless. 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)? And presumably you'd want to take over a whole job at once.... Perhaps I'll try to implement this. One thing's for sure: it should be interesting. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
woods@gpu.utcs.toronto.edu (Greg Woods) (08/27/88)
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. This would be job control for Unix, implemented with the Unix philosophy in mind. In fact, I've heard lots of mainframe type people complain about this lacking feature. [ der Mouse again: ] > But, and I suspect this is the reason this capability isn't available > right now, this isn't good enough. Suppose the job is an editor - vi, > say. The terminal will in general be a different type, implying that > all vi's knowlege about the terminal must be reworked. Unfortunately, > there's no way for vi to find out what the current terminal type is! > Or rather, no practical way. It would require that the shell rewrite > the environment in the vi process. And a mechanism to signal vi that > it has to reread the environment. And nontrivial code in vi to handle > this change. And in every other screen-oriented program. And > rewriting the environment is, in general, not even possible without > kernel modifications so extensive as to amount to half of a rewrite. Part of the necessary mechanisms do exist. SIGCONT tells a process it is continuing from a stop. It might be better if the process could determine if it was continuing in the foreground, or background, though I guess SIGTTIN & SIGTTOU are sufficient. I think it would be wrong to have the kernel sneak in and change a stopped process's environment list. Perhaps a device driver (/dev/environ) could be used by a process, upon SIGCONT, to read a new environment from. Would it read the entire new environment and be able to pick and choose, or would the (new) parent process only make certian values available? Naturally, any complex programme that wanted to take advantage of this new method of job control would require enhancement. 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. Maybe this will be implicit when the child ppid is changed in the process table? [ der Mouse again: ] > 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)? And presumably you'd want to take over a whole job > at once.... Perhaps I'll try to implement this. One thing's for sure: > it should be interesting. The old parent should see an exited child, hopefully with a new exit value from sysexits.h that would reveal its fate. Remember also that SIGCHLD only means that the child's status has changed. 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. Of course children can only be adopted by a parent with the same real or effective UID, or by a superuser process. What kind of security precautions need to be taken by a superuser process? Should this even be allowed by the superuser, since the superuser can always su? If the orphan child is a process group leader, do you adopt the whole family? I think so. If you did this for SysV would there be extensions required to better manage "control terminals"? (These extensions are probably necessary for BSD style Job Control anyway.) I guess a new system call is required: adopt(pid, ttyfd, ...). It's too bad System V doesn't have "real" job control.... Maybe they'd have done it right.... Mabey they will yet.... ISC did their best with their SysV csh implementation in 386/ix, but if you put a job in the background, and then hang up, it never gets SIGHUP. It seems that the background job is in a new process group, without a control terminal, even though it's stdout remains tied to the old tty. It's a quick and dirty way to lock up a port. Termio(7) is far easier to understand and use than newtty(4), but it's just not as feature laden. Termio(7) for SysV needs to be able to generate SIGTSTP, SIGTTIN, and SIGTTOU; these and SIGSTOP must do what they are supposed to do in the kernel; and termio(7) must learn to erase tabs, and not erase past the beginning of the input buffer. Then all of us SysV lovers wouldn't really care to see BSD again! I suppose one could write a new line discipline to understand the tabs and erasing bit, but the kernel needs new hooks for the new signals. Anybody game? I have the feeling you'd end up re-compiling a lot of utilities to hook this stuff in, even if you were careful about the values of new constants (ie: signals), and didn't care to add capability to anything to explicitly use these new features. A new command (ntty) could be written instead of extending stty. Even so, I think you'd need a source license, even if someone else wrote the new modules. Anyone want to prove me wrong by doing it? How about the ability to adopt (migrate) jobs from another machine on a homogeneous network? -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
smb@ulysses.homer.nj.att.com (Steven Bellovin) (08/28/88)
With all due immodesty, let me refer folks to my ``Session Manager'' paper presented at the last Usenix. It provides a clean framework for moving stuff around, though I didn't present a full solution to this exact problem.
duane@cg-atla.UUCP (Andrew Duane) (08/30/88)
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. It would be relatively easy (easy > relative to the other points I'll bring up, that is) to hack some way > into the kernel to transfer ownership of the job from the one shell to > the other. It would even be possible to hotwire its file descriptors > so that the ones that used to point to the old terminal now point to > the new terminal. (Is this enough? You tell me.) > > [stuff about environments, terminal types being changed, > signals required, etc.] > der Mouse From my days in college, I remember TOPS-20 (Twenex) being able to do just about this. There was the DETACH command that detached the current login session from your terminal (there was still a command shell running, but not logged in). From this same "not-login" shell, there was an ATTACH command that would reattach a previously detached session. Does anyone know how TOPS-20 handled the issues mentioned above? Most of them are non-trivial, but at least one system figured them out reasonably. DISCLAIMER: It has been a long (LONG) time since I used TOPS-20. Andrew L. Duane (JOT-7) w:(508)-658-5600 X5993 h:(603)-434-7934 Compugraphic Corp. decvax!cg-atla!duane 200 Ballardvale St. ulowell/ \laidback Wilmington, Mass. 01887 cbosgd!ima/ \cgeuro Mail Stop 200II-3-5S ism780c/ \wizvax Only my cat shares my opinions, and she's breaking in the new help.
mouse@mcgill-vision.UUCP (der Mouse) (08/31/88)
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 <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@larry.mcrcim.mcgill.edu
peter@ficc.uu.net (Peter da Silva) (09/02/88)
Way out in left feild, here... Probably the parent should see the child as having been killed by some new signal. One thing that would make it easier would be to have the process that did the attach become the child's parent. It could intercede between the child and the shell and give the shell its return status. It takes an extra process slot, but what the hey. I don't think that forcing a new environment on the process is going to be easy enough to make it worth the effort. Remember, the environment is in the address space of the process. Anything could have happened to it. On the PDP-11, I had one program that was tight on space trash the environment completely. So, tough luck on screen-based applications unless the terminal is the same and you have a "redraw" command, or else the attach process could move stdout to a pipe and interpret the terminal codes itself... -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
rta@pixar.UUCP (Rick Ace) (09/02/88)
In article <5709@cg-atla.UUCP>, duane@cg-atla.UUCP (Andrew Duane) 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? > > > > [stuff about environments, terminal types being changed, > > signals required, etc.] > > der Mouse > > From my days in college, I remember TOPS-20 (Twenex) being able > to do just about this. There was the DETACH command that > detached the current login session from your terminal (there > was still a command shell running, but not logged in). From > this same "not-login" shell, there was an ATTACH command that > would reattach a previously detached session. > > Does anyone know how TOPS-20 handled the issues mentioned above? > Most of them are non-trivial, but at least one system figured > them out reasonably. > > Andrew L. Duane (JOT-7) w:(508)-658-5600 X5993 h:(603)-434-7934 TOPS-20 had a the concept of a process, similar to that of a process under UNIX. TOPS-20 also had the notion of a "job", which is a set of processes all sharing a common ancestor and that ancestor. In addition to a process-private context data structure, all processes of a job shared a common job-private data structure called the JSB. In the JSB resided a handle on the job's "controlling terminal". When a process chose to write to its "terminal", output was done to the controlling terminal's handle appearing in the JSB. The ATTACH/DETACH feature was simple (in concept) because by changing one location in the JSB, you could redirect the terminals for all processes in the job. A job with appropriate privilege could manipulate certain items in another job's JSB. Roadblocks to making ATTACH work under UNIX: 1. UNIX has no formal concept of a "job" and no per-job database. (This is not the only approach, but it worked well for ATTACH.) 2. Determining which processes belong to which terminals is a nebulous task. 3. Processes have direct handles (file descriptors) on terminals; they do not go indirect a job-common location. About the closest thing to a "controlling terminal" is /dev/tty, but that's not what you'll find at stdin/stdout/stderr. Rick Ace Pixar 3240 Kerner Blvd, San Rafael CA 94901 ...!{sun,ucbvax}!pixar!rta
woods@gpu.utcs.toronto.edu (Greg Woods) (09/02/88)
In article <5709@cg-atla.UUCP> duane@cg-atla.UUCP (Andrew Duane) 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? >From my days in college, I remember TOPS-20 (Twenex) being able >to do just about this. There was the DETACH command that >detached the current login session from your terminal (there >was still a command shell running, but not logged in). From >this same "not-login" shell, there was an ATTACH command that >would reattach a previously detached session. If I remember right, Multics does the same kind of thing, though it would save everything in your session, just like a re-startable core dump. Most usefull something bad happens. I think it would even work for system crashes, as long as they weren't too fatal. -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
hedrick@athos.rutgers.edu (Charles Hedrick) (09/02/88)
While detach/attach on TOPS-20 was a great feature, you should not looks to TOPS-20 for a complete resolution of all the subtle issues raised by this feature. If you were in a program doing fancy terminal handling when you detached, there was a reasonable chance that odd things would happen after you reattached. My favorite idea for doing it on Unix is to do it in telnetd. (This assumes that all users come in via the network, which in our case is true.) Detach would close the network connection to the system, but leave telnetd and the pty alive. THere would then be an attach daemon that would locate the right telnetd and you'd open a network connection to it. The pty would never be disturbed and Unix would go merrily on its way.
jsq@longway.TIC.COM (John S. Quarterman) (09/03/88)
In article <2364@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes: ... >Roadblocks to making ATTACH work under UNIX: >1. UNIX has no formal concept of a "job" Actually, it does: the process group. Csh uses it all the time in job control. > and no per-job database. No, but it has a process group ID and a process group leader. > (This is not the only approach, but it worked well for ATTACH.) Actually you attach to the session, not the job. >2. Determining which processes belong to which terminals is a nebulous task. The nebulous concept in UNIX has been that of a session: what is it, how is it created, and how is it related to the controlling terminal. Particularly so, when in System V there is only one process group per session, while in BSD you can have many. >3. Processes have direct handles (file descriptors) on terminals; > they do not go indirect a job-common location. About the > closest thing to a "controlling terminal" is /dev/tty, but > that's not what you'll find at stdin/stdout/stderr. Ah, but both System V and BSD have controlling terminals. Try looking at vhangup(2) in BSD or setpgrp(2) in System V. The controlling terminal is associated with a process group, and sends keyboard-generated signals like SIGHUP, SIGINT, and SIGQUIT to processes in that process group. The controlling terminal is the one you get when you open /dev/tty. How else it is set up varies with the system, although it's usually by opening a terminal after getting rid of the previous controlling terminal by some implementation-defined method. You may find IEEE 1003.1 (approved 22 August 1988) interesting in this regard. Its definitions of process groups, sessions, and controlling terminals, together with ancillary functions, were written after months of intensive discussion among people from AT&T, UCB, MIT, HP, IBM, etc. Little problems like setpgrp() not being the same thing in BSD and System V, and like nobody really having a good definition of a session to start with, were dealt with (I won't necessarily say ``solved'' for all such problems). TOPS-20-style ATTACH was explicitly considered and the text in the standard is carefully written so that you could implement it with ATTACH and be conformant. You will probably see 1003.1 conformant systems soon (DEC already claims to have one), but I don't know if anybody is actually doing ATTACH.
budd@bu-cs.BU.EDU (Philip Budne) (09/05/88)
While TOPS-20 (and TOPS-10) do have ATTACH/DETACH, they relate to changing the terminal a "job" is attatched to. While this would be wonderful (process trees could be detatched on loss of carrier), it would also be hard to implement in Un*x (As pointed out by Rick Ace). Strangely the gruesome S5 sxt kludge makes ATTACH/DETATCH easier, as it isolates interaction with the physical terminal. S.M. Bellovin described a similar implementation at the SF Usenix called the "Session TTY manager". Hewever it is best to liken to problem of moving a process from one csh to another to the ITS DISOWN/REOWN system calls. Which allow you to alter the shape of a "job tree". ITS has ATTACH and DETACH functions as well. The wonderful thing about the ITS job (process) interface is that processes are manipulated via the file system, each process has a unique name and thus you can manipulate any process without regard to superior/inferior (parent/child) relationships. Phil Budne, Boston University
gwyn@smoke.ARPA (Doug Gwyn ) (09/05/88)
In article <24748@bu-cs.BU.EDU> budd@buita.bu.edu (Phil Budne) writes:
-The wonderful thing about the ITS job (process) interface is that
-processes are manipulated via the file system, each process has a
-unique name and thus you can manipulate any process without regard to
-superior/inferior (parent/child) relationships.
Gee, just like modern UNIX. I imagine OSF won't pick this up
either, since they didn't seem to see any advantage to STREAMS.rta@pixar.UUCP (Rick Ace) (09/07/88)
In article <235@longway.TIC.COM>, jsq@longway.TIC.COM (John S. Quarterman) writes: > In article <2364@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes: > ... > >Roadblocks to making ATTACH work under UNIX: > >1. UNIX has no formal concept of a "job" > > Actually, it does: the process group. Csh uses it all the time in > job control. The UNIX process group is not analogous to the TOPS-20 job. Perhaps my statement should be rephrased to read, "UNIX has no formal concept analogous to the TOPS-20 job." > > (This is not the only approach, but it worked well for ATTACH.) > > Actually you attach to the session, not the job. No, you attach to the job. TOPS-20 does not have "sessions". > >3. Processes have direct handles (file descriptors) on terminals; > > they do not go indirect a job-common location. About the > > closest thing to a "controlling terminal" is /dev/tty, but > > that's not what you'll find at stdin/stdout/stderr. > > Ah, but both System V and BSD have controlling terminals. > Try looking at vhangup(2) in BSD or setpgrp(2) in System V. Whoa! Don't look at vhangup(2) immediately after eating food. It only does half the job (removing access to open file descriptors to the specified tty) and it does it half-baked at that: 1. background process A does read(2) or write(2) to tty and gets put to sleep in tty.c 2. vhangup(2) gets called 3. process A unblocks and continues to read from or scribble on tty device after vhangup has revoked authorization The other half of the job, namely executing the line-discipline and driver "close" routines, is not guaranteed to happen when vhangup is called. In short, vhangup is an expedient solution to a problem that should rightfully be solved by a revision of the design of terminal ownership and session semantics under UNIX; it is hardly valuable as an illustration of anything other than that. Rick Ace Pixar 3240 Kerner Blvd, San Rafael CA 94901 ...!{sun,ucbvax}!pixar!rta
peter@ficc.uu.net (Peter da Silva) (09/08/88)
In article <2364@pixar.UUCP>, rta@pixar.UUCP (Rick Ace) writes: [ bunch of included text deleted ] > Roadblocks to making ATTACH work under UNIX: > 1. UNIX has no formal concept of a "job" and no per-job database. > (This is not the only approach, but it worked well for ATTACH.) A process group matches pretty well to a 'job'. > 2. Determining which processes belong to which terminals is a nebulous task. There is a pointer from the terminal to the job somewhere, since a process group is killed (with SIGHUP) when the head of that process group exits. It may just go through the process table hitting all the jobs that have the same pgroup as the process that exits, but there is that handle. > 3. Processes have direct handles (file descriptors) on terminals; > they do not go indirect a job-common location. About the > closest thing to a "controlling terminal" is /dev/tty, but > that's not what you'll find at stdin/stdout/stderr. And the open routine for /dev/tty has to know about a processes control terminal, so the information is there... 1. You create a pseudo-device that looks pretty much like /dev/null, and attach all the file handles that refer to the control tty of each process in that process group to the pseudo-device. 2. You then change the control terminal of that process group to this pseudo-device. Now you have all the processes isolated in a nice little job. 3. To re-attach, you just repeat steps one and two for the new control terminal. This would require kernel hacking... and not just a device driver. But if you put some streams between the control terminal and the process it may be possible to do something like this without undue harm... -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net