Tag Info

New answers tagged

0

"Kill Me Softly" I just ran across project with a couple of small shell scripts for this. https://github.com/alanfranz/killmesoftly


3

You could use wmctrl to gracefully close all windows of a particular application1 (as far as I know it's "as clean as if the application was closed using menu->Exit"). using app wm_class: for win in $(wmctrl -lx | awk '$3 ~ /Icedove/ {print $1}'); do wmctrl -ic "$win"; done using app pid: for win in $(wmctrl -lp | awk -v icepid=$(pgrep icedove) '$3 == ...


4

SIGTERM allows a process to perform cleanup before it terminates, but whether or not the process actually does so, and what sort of cleanup it performs, depends on how the program was written and (to an extent) on the facilities that the language the program was written in provides. So when a program receives SIGTERM it's not obliged to save anything, but ...


2

There is no "file" like you want to see, unless you want to read kernel code. This is a little oversimplified. See the chapter in Rago & Stevens on Signals in 'Advanced Programming in the UNIX Environment' for a lot more information. There are two parts to 'default signal handling'. These are built into the kernel. When the scheduler notices that ...


4

You can use word notation for more readability : kill -STOP <PID> # pause kill -CONT <PID> # continue working Check man 7 signal


-1

use set -e to exit from failure. #!/bin/bash set -e while : do sl done


1

There is no permission structure for processes like there is for files. Thus you need tricks like sudo or a SUID / FSCAP binary.


1

The problem is limiting damage. You can get quite close with sudo. Consider this sudoers entry: %group1 ALL = (user1) pkill -HUP <name of process> Then members of group1 can do: sudo -u user1 pkill -HUP <name of process>


4

It's not quite that SIGTERM isn't working, it's that the application doesn't react to it the way you are hoping. Generally, the purpose of catching SIGTERM is to do some tidying up, such as syncing data to disk, etc., before exiting. There's no enforced requirement, however, that the process actually exit, so if something goes wrong during whatever it does ...


0

This is not an answer, but... $ cat Trap.sh #!/bin/bash echo "Trap.sh is PID $$" trap -p grep Sig /proc/$$/status trap 'echo SIGINT' SIGINT trap -p grep Sig /proc/$$/status trap 'echo SIGTERM' SIGTERM trap -p grep Sig /proc/$$/status trap 'echo SIGUSR1' SIGUSR1 trap -p grep Sig /proc/$$/status $ ./Trap.sh Trap.sh is PID 13887 SigQ: 0/63517 SigPnd: ...


0

You can test it out quickly enough: $ cat test.sh trap : INT HUP USR1 sleep 10h $ ./test.sh & [1] 29668 $ grep SigCgt /proc/$(pgrep test.sh)/status SigCgt: 0000000000010203 $ grep SigCgt /proc/$(pgrep sleep)/status SigCgt: 0000000000000000 So trap doesn't affect binaries. What about scripts? $ cat blah.sh #! /bin/bash grep SigCgt ...


0

As @Mat shows in his answer, a SIGSPEC of 0, when used on the trap command will cause the trap command to run when the script exits. This example illustrates what happens. $ cat tr.bash #!/bin/bash echo "PID: $$" trap 'echo hi; exit 1' 0 1 2 15 while [ 1 ]; do sleep 3 done When we run this: $ ./tr.bash PID: 24086 It sits here waiting ...



Top 50 recent answers are included