prkl Author: Juhapekka Tolvanen http://iki.fi/juhtolv juhtolv (at) iki (dot) fi These script are public domain. There is no warranty. Except prkl.pl really has no license, at all. It is written by: Urpo Lankinen http://iki.fi/wwwwolf wwwwolf (at) iki (dot) fi These scripts are meant to easily kill all processes related to Mozilla Firefox, Netscape Navigator, Netscape Communicator etc. They do not hurry up using signal -9 , but use gentler signals, first. But you can use these scripts to kill any processes whose killing is complicated in same ways I have explained in this text file. And I really said processes, not just process. Those WWW-browsers fork some processes having some other name than than browser itself. Therefore plain “killall firefox” or “pkill firefox” is not enough. Finding killable processes from output of ps-command is just a waste of time when compared to using these scripts. On the other hand, those commands (and “ps xf | less”) are very slow to write, when WWW-browser or other process goes so wild that my computer becomes almost unresponsive. It is easier to just type “prkl” and hit Return. These scripts use command killall. Hence, these scripts do not work as meant under Sun Solaris, because in that Unix-flavour killall is totally different command. You can use command pkill, instead; just edit those scripts you choose. Actually pkill is available in the most common GNU/Linux-distributions, too: In my Debian GNU/Linux pkill belongs to a package called procps and killall belongs to a package called psmisc. You may need to change that shell that is mentioned in first line of each script. /bin/dash is a default shell in Debian GNU/Linux and most of its derivatives, for example Ubuntu Linux ; Under those operating systems /bin/sh is just a symbolic link pointing to /bin/dash . If in doubt, just use /bin/sh instead of /bin/dash . Names of these scripts come from common Finnish cursing word “perkele”. Sometimes it is written without vowels in Internet and then it becomes “prkl”. http://en.wikipedia.org/wiki/Perkele http://fi.wikipedia.org/wiki/Perkele That word often comes to my mind, when my WWW-browser hangs or start to swap so much that my computer becomes almost unresponsive. Signals have been chosen after this advice: http://partmaps.org/era/unix/award.html#uuk9letter http://www.softpanorama.org/Scripting/Shellorama/humor.shtml ---- Clip here ---- No no no. Don't use kill -9. It doesn't give the process a chance to cleanly: 1) shut down socket connections 2) clean up temp files 3) inform its children that it is going away 4) reset its terminal characteristics and so on and so on and so on. Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1. If that doesn't, REMOVE THE BINARY because the program is badly behaved! Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot. Just another Useless Use of Usenet, ---- Clip here ---- But removing the binary is totally weird idea. Therefore my scripts use signal “-9”, but latest scripts use it only as a last resort. Waiting “a second or two” is handled, too. Actually, most of these scripts wait more than two seconds between each kill-command. You may even want to comment away some of those sleep-commands in those scripts. Explanations of signal numbers are: 15 : TERM 2 : INT 1 : HUP 9 : KILL Memorizing that litany of signals especially in a hurry is too difficult for me; that is yet another reason to create these scripts. You can find a better explanations for those signals from man page of command “kill”. You may need to edit lists of process names; just use command ps or even pstree to find proper names for those processes. Latest script send signals only to Mozilla Firefox under Debian GNU/Linux and its forked processes, by default. That process name /usr/lib/xulrunner-17.0/plugin-container must be changed every time when a new major-version of Firefox has been released. Explanation of process names in those scripts is this: I started creating these scripts, when I used some kind of Netscape under Red Hat Linux. Netscape was available both dynamically and statically linked against Motif-libraries. Then came Netscape Navigator and Netscape Communicator. Later I switched to Debian GNU/Linux and it used different names for its Netscape-binaries and -processes. Then came Mozilla-project. First they created just plain Mozilla. Then came Mozilla Firefox. Its process name is firefox-bin. Then I installed, used and maintained Ubuntu Linux at work. I was once again faced with yet another name of proces of WWW-browser. This time name of process was firefox. That xulrunner-stub is a weird process; I have seen that process name only in a software called gmemusage but never in output of ps-command. Maybe it is not really a process but a thread. I try to kill it, too. You must put scripts you choose to some directory that is mentioned in environment variable called $PATH . Then go to that directory and set right permissions for those scripts: chmod u+rx *prkl* Finally create a symlink called “prkl” pointing to latest version of actual script: ln -s prkl.04.sh prkl That way you only need to give simple command “prkl”. My latest addition to prkl scripts is gxprkl. It is meant to be binded to some key binding of my window manager. Sometimes my computer may become so slow, that finding or starting some terminal emulator becomes very slow. In that situation a keybinding is a better idea. As the name suggests, gxprkl uses messageboxes with Gtk+-widgets in order to inform user. It depends on a program called gxmessage: http://homepages.ihug.co.nz/~trmusson/programs.html http://savannah.gnu.org/projects/gxmessage/ http://ftp.gnu.org/gnu/gxmessage/ First gxprkl launches prkl-command and pipes its all output to gxmessage; that command is started on background. Immediately after that gxmessage is launched with a message telling that prkl-command is launched. After prkl has exited, its output is shown in gxmessage-window. You may need to edit sizes of windows and fonts in that gxprkl-script. Of course, you can bind just plain prkl-command to some keybinding, but then you need other measures to ensure that prkl really runs. On the other hand, if you are interested in output of prkl, you need to checkout output of that command from a file ~/.xsession-errors . And you may accidentally try to restart your WWW-browser when prkl-script is still running and then that WWW-browser becomes killed again. Anyway, it may be a good idea to bind gxprkl to some keybinding and prkl to some other keybinding; it may be possible, that some day computer is under so much stress that even launching gxmessage is too big job for it in that particular situation. And why not binding some simpler version of prkl-command to the third keybinding. Here is a part of my .fvwmrc : ----- Clip here ---- ## http://iki.fi/juhtolv/hacks/sh/mozilla Key F5 A C Exec exec ${HOME}/scripts/gxprkl & Key F6 A C Exec exec ${HOME}/scripts/prkl & Key F7 A C Exec exec ${HOME}/scripts/prkl.03.sh & ----- Clip here ---- That gxprkl-script also kills all gxmessage-processes after some time, because you may accidentally press your key binding too many times or keep keys of that key binding pressed too long time. In that case many gxprkl-commands are launched and after a while you screen is full of gxmessage-windows.