lee@unm-ivax.UUCP (07/31/83)
If all the proc table slots (except one for root) are gone and you log in as root it will probably be a bit hard to do a 'ps' as you just took the one reserved for root when you logged in. --Lee Ward ...!ucbvax!unmvax!lee
guy@rlgvax.UUCP (Guy Harris) (08/02/83)
Since the "getty"/"login" you talked to already had a process slot, which it
gave up to your super-user shell, you still can take the last process slot for
one process/command, so you can still type the "ps" (unless, of course, it's
a privileged process that's running wild).
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guynrf@whuxlb.UUCP (08/02/83)
#R:unm-ivax:-53700:whuxlb:900017:000:195 whuxlb!nrf Aug 2 15:00:00 1983 if you log on and get a shell, you can always do exec /bin/ps and use the same proc slot as the shell. (this is if someone else gets on and grabs the last slot, or some su cron entry gets it.
dbj.rice@rand-relay@sri-unix.UUCP (08/03/83)
From: Dave Johnson <dbj.rice@rand-relay>
If all the proc table slots (except one for root) are gone and
you log in as root it will probably be a bit hard to do a 'ps' as
you just took the one reserved for root when you logged in.
You've probably gotten about 3000 replies already that say this, but here
goes: When you log on, you don't take up any more proc table slots since
there is always a process for each terminal already running waiting for
somebody to walk up and type a user name on the terminal. If the terminal
is a dialup, this process is hung on the open of the terminal line in init,
while if the terminal is hardwired and there is always a carier on the line,
the process has execed getty, and the process is hung reading the user name
from the terminal. In either case, once you get logged on, this process
then execs the shell, so no new process is needed. You still have that
spare proc table slot for your "ps" command and then for a "kill" command to
kill the offender.
Right as you log off, though, the "login" process for that terminal finally
exits, and init must fork a new one to take its place. If you ran out of
proc table slots just as this was happening, init's fork for this new
process would take up the last proc table slot (the one reserved for root)
since init runs as root. Even in this case, though, you'd be able to log on
since there was a proc table slot left for this process. Then, after
getting on, you could exec the "ps" command from your login shell with the
"exec" command built in to both the Bourne shell and C-shell. This would,
in effect, log you off, but that's no problem -- init would just fire up a
new process for that terminal taking the newly vacated process slot (it can
take the last slot again since it's running as root), and you just log on
again and exec another command the same way. Eventually, you could get in
enough commands to find out who is taking up all the proc table slots and do
a "kill" command on him.
Dave Johnson
Dept. of Math Science
Rice University
dbj.rice@Rand-Relaygwyn@brl-vld@sri-unix.UUCP (08/03/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> Logging in shouldn't take up any proc slots that weren't already in use. Init already forked a getty which will exec login which will exec the shell.
lee@unm-ivax.UUCP (08/07/83)
My apologies to all who read my trash. If I had stopped to think, I too would have come to the same conclusion. I tried to cancel the article, but guess it didn't go. Oh well... My thanks to my peers here who actually use their gray matter here for correcting me and giving me the chance of cancelling the original. again my apologies, --Lee ...!ucbvax!unmvax!lee