sukill: Stopping Unruly Processes
Steven G. Isaacson
A runaway process on a small system isn't much of a
easy enough to identify the guilty process and its owner
either the owner or a user with the root password "fix"
On a large system with dozens or hundreds of users,
a more formal
approach is required. In this case, what's needed is
a tool that allows
an ordinary user to kill another user's process without
The kill Command
Processes can be stopped with the kill command.
kill [ -signal ] pid ...
The kill command sends a signal to the specified process-id
(you determine the correct process-id using the ps
Many different signals may be sent to a process -- the
interrupt, quit, exceeded CPU time limit, floating point
kill, bus error, segmentation violation, user-defined
of a child -- but the two signals most commonly sent
termination (signal 15) and kill (signal 9). These two
in /usr/include/sys/signal.h as SIGTERM and SIGKILL.
SIGTERM is the default signal sent by kill. It provides
a warning that can be caught by the process and thus
be dealt with
or ignored. vi, for example, catches the signal and
up its temporary files before exiting.
SIGKILL, however, cannot be caught or ignored. It terminates
the process immediately.
The problem with the kill command is that it requires
user provileges to kill a process other than your own.
To make it
generally available, you could choose to create a set-uid
of the command (i.e., /bin/kill).
A set-uid program temporarily changes the effective
user id of whoever
is running the program. If the user id is set to root,
any user who
runs the program has root privileges.
Thus if you make kill a set-uid root program, the user
temporarily acquire root privileges and will be able
to kill any process
on the system.
Set-uid programs are potentially dangerous, however,
and should generally
be avoided. In the case of the kill command, any user
any other user's process and no one would be the wiser;
any user (when running as root) could bring down the
system by killing
sukill provides a better way to stop unruly processes.
sukill [ -signal ] pid ...
sukill is similar to the kill command except
that it allows you to kill processes other than your
own. It does
not, however, automatically give every user on the system
sukill has three safeguards: it restricts the range
process-ids that can be killed; it can be used with
and "deny" files; and it logs an audit trail.
sukill does not allow you to kill a process-id less
This prevents users from inadvertently (or intentionally)
down the system, which could happen if they're allowed
to kill system
One hundred is a happy medium between the system processes
started at boot time -- for example, init, sendmail,
and cron -- and user processes. The ability to kill
processes should be left to the system administrator.
If this value
is too high or too low, you can easily change it.
Allow and Deny
sukill can be used with "allow" and "deny"
files. These are files that contain a list of users
who are allowed
or denied access to sukill.
To permit specific users to run sukill, add their lognames
to the sukill.allow file. To deny particular users,
lognames to sukill.deny.
If neither sukill.allow nor sukill.deny exists, then
every user has permission to execute sukill. If you
these files, set their permissions so that only root
can write to
In practice the allow and deny files are seldom used,
because of sukill's verbose logging. However, different
have different requirements, and you may find that allow
deny files are appropriate.
sukill writes the following information to the log file:
sukill command-line arguments (the optional signal level
the pid(s) to be killed); system date and time; logname
id, group id, effective user id (always 0 unless sukill
is not installed
correctly), effective group id, current user id name,
directory, values of $HOME and $NAME environment variables;
and finally the results of a verbose listing from /bin/ps
the specified pid(s).
The output from /bin/ps is exactly what you would expect
"reasonable user" to look at before killing
process. In fact you must use the ps command to obtain
pid number. Figure 1 shows a sample logfile entry.
The entry reveals that a process owned by sneed was
killed by jamesy
and that jamesy used -9, the SIGKILL signal. The file
shows that the process that was killed had no controlling
and had been going for three hours and two minutes.
The log file is not pretty and is seldom examined, but
if a problem
does occur -- a user's program keeps stopping unexpectedly,
-- it provides an audit trail.
Listing 1 contains all of the source for sukill. Simply
it, change the owner to root, and change the permissions
The logging section may have to be customized for your
could be made less verbose or could perhaps have installation-specific
requirements added to it.
sukill is a simple and safe way to give more power to
You may even find that you use it yourself instead of
to su to root in order to kill a process.
About the Author
Steven G. Isaacson has been writing C and Informix
since 1985. He is currently developing automated testing
FourGen Software, the leading developer of accounting
CASE Tools for the UNIX market. He may be reached via
uunet!4gen!steve1 or email@example.com.