Managing processes from previous logins
Last revision August 9, 2004
The process control features so far described (jobs, CTRL-Z, fg, bg, and kill) affect only processes that are children of the current login shell. Once you logout, any background jobs from that login session become simple detached processes, and you cannot control them with kill, bg, or fg from a future login session. There are other commands to get information about detached processes (or processes of other people) and affect them (if you have the privilege).
who shows who else is logged on to the computer. w is a variant that tries to show more information about each login.
ps can be used to show the status of any process on the computer. By default, it gives information about all processes created by your current login shell. Options let you control the amount of information displayed or show processes created during previous login sessions or owned by other accounts.
Unfortunately, there is a major difference in the names and meanings of options between the Berkeley and System V Unix versions of ps, and there are also minor differences between different vendor implementations of the same version. Pangea supports both Berkeley and System V options. On pangea, the following Berkeley style syntax will show all the processes running under your account, from the current or previous logins, with lots of information about resource usage and the entire list of arguments with which the command was started (wrapping onto succeeding lines as needed). NOTE that the Berkeley ps option syntax does not use a hyphen character to introduce the options.
ps uxww
On a straight System V Unix version of ps (for example, SGI), the following ps options will give you most of the same information as the command described above:
ps -fu loginname
where you substitute your own login name for loginname.
kill can be used to kill another process from a previous login by giving the process id number (obtained with the ps command) as an argument. You cannot kill processes owned by other accounts unless you are the super-user.
Remember that the entire line of typed input is a single job to the shell even though each program in the pipe or command sequence is a separate process and will show up separately in a ps display.
For example, suppose you had a login session to pangea and was running the
pine email program, which then got stuck and would
not respond (perhaps due to a bug in your local computer's telnet program). You
could open another login window and run ps uxww to find out information
about all your processes, including this stuck pine
process from the previous login. You might get a result like this (slightly condensed
and lines wrapped for display).
USER PID %CPU %MEM VSZ RSS TTY S STARTED TIME COMMAND
farrell 18989 0.3 0.0 2.38M 168K ttyt3 S 09:04:08 0:01.03 -csh (csh)
farrell 19075 0.0 0.0 1.79M 0K ttyt3 I 09:04:08 0:00.10 login -h
toiyabe Stanford.EDU -p -F farrell
farrell 17360 0.0 0.0 1.79M 0K ttyt4 I 09:04:35 0:00.09 login -h
toiyabe Stanford.EDU -p -F farrell
farrell 18832 0.0 0.0 2.38M 24K ttyt4 I 09:04:36 0:01.41 -csh (csh)
farrell 19459 0.0 0.0 6.55M 144K ttyt4 I 09:05:29 0:03.66 /local/bin/pine3.93
Here, the processes shown on terminal port ttyt3 (TTY column) are from the new login session (you can verify this by running the simple command tty, which will show you the terminal port of my current login), and the old session, with its stuck pine process, is represented by the processes on port ttyt4. From this new login session, you can now kill that old pine process and the login processes that started it using the kill command and the process id numbers, shown in the PID column of the ps output, for example:
kill 19459 18832 17360
The plain kill command, with no options except one or more process id numbers, is equivalent to typing the CTRL-C interrupt key when the process is in the foreground. If the process will not die from this signal (which is common if it is stuck), then you can send the stronger kill signal using the -KILL option, for example:
kill -KILL 19459 18832 17360
But remember that this option does not allow the process to clean up, so it should be used only when a process does not respond to the normal interrupt (plain kill).
| <--Previous | Overview | |