[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-users] Kill
> Zeffie wrote:
>
> > kill?
> > I come from a dos win enviroment. and I can't help but feel that even
if I
> > kill some process I'm leaving memory gaps, or something that can cause
> > problems down the line. can anyone give me the confidence I so rarely
need
> > to kill something? and explain to me why this is a better solution?
You won't be leaving memory gaps or any other problems from killing
processes. Actually, kill by default sends the SIGTERM (aka 15) signal,
which is _defined_ as a graceful exit. Processes are allowed to handle that
signal themselves, so many will clean up gracefully when they are ready.
kill also accepts an arbitary signal, specified either by (shortened) name
or number. If you have a process that doesn't respond to a SIGTERM, a
SIGKILL (aka 9) will nuke it, whether it likes it or not. Note it will _not_
cause memory problems, but will very probably leave pid files or other
residue on the filesystem, which usually isn't a problem to clean up. (Many
daemons will automatically clean up such problems when restarted..)
You can specify SIGKILL rather than SIGTERM using `kill -9 <pid>` or `kill
-SIGTERM <pid>` or `kill -KILL <pid>`.
Another common use for kill is to send a process the SIGHUP signal (aka 1),
which is often used to mean "re-read your configs" or "restart". This can be
done with `kill -HUP <pid>`. Note that unless the process actually is known
to have this feature, sending SIGHUP will also ask the process exit. Check
the docs first :)
There are many other signals as well, but those are the most useful to
known, in my experience.
--
David Zanetti, Unix Systems Administrator and Postmaster
Wellington City Council, New Zealand. Phone +64-4-801-3354
The light at the end of the tunnel is a train heading for you.