You're right of course. I should have said SIGKILL, but I've got into
a habit of trying to kill processes with kill -15 instead of kill -9,
and I guess I wasn't thinking.
Anyway, my most recent project has involved creating a kind of daemon
process running under Taskman, and I naturally
Comments below.
-- Bhaskar
Gregory Woodhouse wrote:
You're right of course. I should have said SIGKILL, but I've got into a
habit of trying to kill processes with kill -15 instead of kill -9, and
I guess I wasn't thinking.
[KSB] You're doing the right thing. 15 is normally recommended
This is neither here nor there, but when I'm *going home* from work, I
walk up the stairs out of the BART (subway) station, cross the street
and take the bus (yeah, and I know that's a signal, too, but I won't go
there). Anyway, I catch the 15 to get home, but the 9 bus stops there,
too (and we
, 2005 2:09 PM
To:
hardhats-members@lists.sourceforge.net
Subject: [Hardhats-members]
Dealing with FileMan hangups
When Kernel or FileMan hangs there are several ways to deal
with the problem from just wait to Ctrl C abort. I wonder what the least
damaging tactic would be. Ctrl C; restart Cache
An interesting thing I discovered under DSM is that there is no way to trap a forced exit (e.g., to do cleanup in a way analogous to a finally clause in Java). Under Unix, of course, there are signals that cannot be caught or ignored (like SIGTERM), but it is also possible to send a catchable
: [Hardhats-members] Dealing
with FileMan hangups
An interesting thing I discovered under DSM is that there is no
way to trap a forced exit (e.g., to do cleanup in a way analogous to a finally
clause in Java). Under Unix, of course, there are signals that cannot be
caught or ignored (like
When Kernel or FileMan hangs there are several ways to deal
with the problem from just wait to Ctrl C abort. I wonder what the least damaging
tactic would be. Ctrl C; restart Cache(or other software), reboot the system,
or other options?
Thanks,
thurman
