COMMAND
Xfree
SYSTEMS AFFECTED
Xfree
PROBLEM
Jim found following. While killing yet another zombie Netscape
process, he made the mistake of typing
kill -9 -1 <pid>
as opposed to the normal "kill -9 <pid>." For obvious reasons,
this attempted to kill every process owned by its user and hung
the entire system in the process (aka. he couldn't even switch to
another console to attempt recovery). Unfortunately the only way
to recover is to "hard boot" the system and run the risk of
corrupting root partition in the process (happens). Actually the
network connection (if one has one) still works. KJ. tried out
the above and he faced the same situations as you did for rh 6.0
afterstep and slack 4.0 with window maker. He had to ssh in and
do a /sbin/reboot... it's not a solution, but better then maybe
corrupting one's partitions.
Same results are under FreeBSD 3.2 with XFree86 3.3.3.1 and
FreeBSD 4.0 with XFree86 3.3.6, so it seems to be common
(XFree86?) problem. Since X server can be launched via telnet
session it's not necessary to be console user to crash console
this way.
SOLUTION
Nothing yet. If you're running a box that doesn't have others
accessing it that you don't trust, turn on the Magic SysRq key
support in your kernel. That way if something bad like this
happens, you can type:
alt - SysRq - U
alt - SysRq - S
alt - SysRq - B
and your machine will reboot without the file system being
corrupted.
-1 as a process ID argument to kill is handled by SVR4 and 4.3+BSD
by sending the signal to all processes whose real UID or saved UID
is the real or effective UID of the process sending the signal
(except the signal sender if under 4.3+BSD). So what you're
actually doing is just killing all of your processes. You could
just as well whack them all by hand. If you're root it'll hit
about everything on the system. (see W. Richard Stevens
"Advanced Programming in the Unix Environment" under "kill and
raise functions", p. 283-4 for more info on this). It is standard
behavior, and not a bug. You still can't kill others' processes.