Tag Info

New answers tagged

1

The signals are sent in the order that you type them via the terminal to the kernel. If you use Ctrl+C you're instructing the kernel to send the signal SIGINT, to the foreground process group. Upon receiving this, the command that was running will be terminated. With a Ctrl+Z you're sending the signal SIGSTP. Which doesn't actually kill the process, just ...


3

Part of your problem is that you have the >> trap.log outside the (quoted) command arg, so all you’re getting in the trap.log file is the output from the trap command itself – which is nothing. I’m not sure what you mean by saying “TRAPPED & READY” when your script is terminating, but it looks like what you mean is trap 'rm -f filename; echo ...


2

Use EXIT instead of the signal numbers. The script below works for me. I use the constants. > cat test.sh #!/bin/bash trap 'echo trap' EXIT echo 'Program running' sleep 1 > ./test.sh Program running trap From the bash manpage: If a sigspec is EXIT (0) the command arg is executed on exit from the shell. If a sigspec is DEBUG, the command ...


0

The question contains its own answer. Sending the SIGINT to the cat process with kill is a perfect simulation of what happens when you press ^C. To be more precise, the interrupt character (^C by default) sends SIGINT to every process in the terminal's foreground process group. If instead of cat you were running a more complicated command involving multiple ...


4

How CTRL+C works The first thing is to understand how CTRL+C works. When you press CTRL+C, your terminal emulator sends an ETX character (end-of-text / 0x03). The terminal is configured such that when it receives this character, it sends a SIGINT to the foreground process group of the terminal. This configuration can be viewed by doing stty and looking at ...


5

As vinc17 says, there’s no reason for this to happen.  When you type a signal-generating key sequence (e.g., Ctrl+C), the signal is sent to all processes that are attached to (associated with) the terminal.  There is no such mechanism for signals generated by kill. However, a command like kill -SIGINT -12345 will send the signal to all processes in ...


2

There's no reason to propagate the SIGINT to the child. Moreover the system() POSIX specification says: "The system() function shall ignore the SIGINT and SIGQUIT signals, and shall block the SIGCHLD signal, while waiting for the command to terminate." If the shell propagated the received SIGINT, e.g. following a real Ctrl-C, this would mean that the child ...


1

Yes, there is a difference. This script will exit when you press Enter, or send it SIGINT or SIGTERM: trap '' EXIT echo ' --- press ENTER to close --- ' read response This script will exit when you press Enter: trap '' EXIT INT TERM echo ' --- press ENTER to close --- ' read response * Tested in sh, Bash, and Zsh.   (no longer works in sh when you add ...


1

No. The main signals which are conventionally used by a user to kill a process are: SIGINT (sent by Ctrl+C in a terminal) — abort the current operation and go to the toplevel interactive loop. If the program doesn't have a toplevel interactive loop, kill the program. SIGTERM — stop the program cleanly. This may do an emergency save. SIGHUP — sent by the ...


0

The terminal is not aware of the signals sent to such processes thus won't tell you anything. But if your shell has job control, it can tell you when a background job terminates (e.g. due to the signal). For instance, with bash and zsh, you need to setopt the notify option so that you get such a report immediately (instead of waiting for the next prompt). ...


2

Try: #!/bin/bash _term() { printf "%s\n" "Caught SIGTERM signal!" kill -TERM $child 2>/dev/null } trap _term 15 echo "Doing some initial work...."; exec /bin/start/main/server --nodaemon & child=$! wait $child Normally, bash will not call trap handler when it's waiting child process. Using exec, your server will be start in a ...


0

You can kill the pid of shell (bash). I just tried and it works. Because I cannot see the process from ps -ef (the job that we run in the looping script).


0

I approve of the answer by goldilocks. But instead of using the system call read to check for filesystem changes, one can use inotify. Its man page is here and here. There is an excellent explanation and example by the creators (developers) of inotify here.



Top 50 recent answers are included