In this case you have to use only bash inbuilt features (which include bash
builtins, special builtins as well as looping, variable manipulation and
redirection capabilities of bash).
Following techniques come to mind (though I have never used/tested any of
them!):
1. Since process IDs are visible in /proc and kill is a bash builtin.
Therefore we may use the following simple shell script. This was the first
solution I thought of. It is quick and dirty solution but it will save you
from a reboot (if you are not running as a superuser):
cd /proc;
for i in *; do echo kill ${i/[!0-9]*/}; done;
This attempts to send SIGTERM to all processes. So, it also kills your
useful processes too (like shell you would be typing this command on!).
A more refined approach would be the following script that tries to kill
all process of a specified name. I tried this on my machine for bash. You
may type ruby or whatever you typed on command line. This script does not
start a new process.
/***/
cd /proc
for i in *
do
if [ -f $i/cmdline ]
then
read $i/cmdline
if [[ $REPLY == bash ]]
then
echo kill $i
fi
fi
done
/***/
2. I am not familiar with ruby and what you exactly did. But, if this
technique work, it is better than first one - Use bash builtin named
jobs, to see if the offending process was started as a bash job. If yes,
use kill to send signal to the Jobspec.
Also remember that you may also send signal to process group instead of
sending it to individual processes. Whether it would be better or not would
depend upon how exactly you started the process that is spawning others.
But if you used a script to start whatever you were doing, then they would
almost certainly belong to same process group and it may be easier for you
to find process id of that script. That process id would be the process
group id of all the spawned processes. Therefore you may use kill
-pid_of_script (note the - sign) to kill all the processes started by that
script.
HTH,
Anoop
On Sat, Feb 2, 2013 at 10:05 PM, Chirag Anand anand.chi...@gmail.comwrote:
On 2 February 2013 21:54, Amar Akshat amar.aks...@gmail.com wrote:
Chirag,
I understand your point of pkill, but I don't think you got my question.
Basically, my system runs into a state, where all you can run are the
bash
commands, like echo, cat etc.
Any system command like ps won't execute, perhaps because the system
can't
find resources to execute them and it will exit saying : cannot fork();
Ah okay. Only bash built-in commands I haven't used for this purpose,
in fact I did not even think of them as such at that time. Well 'kill'
itself is a built-in command, but it requires a pid or jobspec, which
I don't think you will be able to get at that time.
On Sun, Feb 3, 2013 at 1:16 AM, Chirag Anand anand.chi...@gmail.com
wrote:
On 2 February 2013 20:49, Amar Akshat amar.aks...@gmail.com wrote:
Hi,
Other day I was writing a small pro-active system monitoring script in
Ruby, and I forgot to close my IO pipe for pgrep command, every time I
checked my system status.
So after a day, there were more than 32,000 zombie pgrep processes. I
could
only run bash commands and nothing else.
I could only find out number of processes due to bash-completion in
/proc/
directory.
So I had to reboot my system.
However my concern is, in a case like this, is there a way we could,
find,
kill the processes by just using bash utilities.? I tried Googling it,
and
found a couple of answers, but I am sure you would have run into such
situations before.
Hi Akshat, in such situations, I generally recommend using pkill
(perhaps with -9), and _patience_ to kill all the instances of that
particular process. It may not get triggered instantaneously but
definitely does the job. You might want to keep doing it until you
have killed the source which is forking every second. 'ps aux | grep '
also comes in handy, but again takes some time, but gives you a sense
of how many processes are left to kill.
I have faced similar situations as these, where I have managed without
a reboot. The thing which you would want to keep in mind is if there
are other users using the process, make sure you are not killing
those, and watch out for the critical ones (for example ssh, network
etc. services).
--
Chirag Anand
http://atvariance.in
--
Thank you...
Amar Akshat (アマール)
Walking on water and developing software from a specification are easy
if
both are frozen.
--
Chirag Anand
http://atvariance.in
___
Ilugd mailing list
Ilugd@lists.linux-delhi.org
http://frodo.hserus.net/mailman/listinfo/ilugd
___
Ilugd mailing list
Ilugd@lists.linux-delhi.org
http://frodo.hserus.net/mailman/listinfo/ilugd
