Hot answers tagged signals
32
What it does is entirely application specific. When you press ctrl+c, the terminal emulator sends a SIGINT signal to the foreground application, which triggers the appropriate "signal handler". The default signal handler for SIGINT terminates the application. But any program can install its own signal handler for SIGINT (including a signal handler that ...
24
From man 2 kill:
The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally.
That is, it is possible for init to do whatever it likes upon receiving SIGKILL (including exiting), but systemd's init does not ...
18
There are a number of signals whose default disposition is to terminate the process. The ultimate termination signal is SIGKILL since it cannot be handled and the process has no choice but to die. This however also means that if you send it, the process is deprived of an opportunity to clean up. Therefore, good manners require to send a signal like SIGTERM ...
13
In addition to processes calling kill(2), some signals are sent by the kernel (or sometimes by the process itself) in various circumstances:
Terminal drivers send signals corresponding to various events:
Key press notifications:
SIGINT (please go back to the main loop) on Ctrl+C,
SIGQUIT (please quit immediately) on Ctrl+\,
SIGTSTP (please suspend) on ...
13
What about this:
foo=`{ { cat 1>&3; kill 0; } | { sleep 2; kill 0; } } 3>&1`
That is: run the output-producing command and sleep in the same process group, a process group just for them. Whichever command returns first kills the whole process group.
Would anyone wonder: Yes, the pipe is not used; it's bypassed using the redirections. The ...
13
SIGINT, the signal sent by Ctrl+C, conventionally tells a program to break out to its main command processing loop, or if that doesn't make sense, to exit cleanly. Some programs run a cleanup procedure when they receive a SIGINT. If the program is so messed up that the cleanup procedure fails, in some programs, a second Ctrl+C causes the program to quit ...
12
Nohup sets the default behavior of the HANGUP signal, which might get overriden by the application. Other signals from other processes with permission (root or same user) or bad behavior (seg faults, bus errors) can also cause program termination. Resource limitations (ulimit) can also end the program.
Barring these, your infinite loop might well run a very ...
11
You cannot kill a <defunct> (zombie) process as it is already dead. The only reason why the system keeps zombie processes is to keep the exit status for the parent to collect. If the parent does not collect the exit status then the zombie processes will stay around forever. The only way to get rid of those zombie processes are by killing the parent. If ...
11
Shell jobs live in "process groups"; look at the PGRP column in extended ps output. These are used both for job control and to determine who "owns" a terminal (real or pty).
POSIX (taken from System V) uses a negative process ID to indicate a process group, since the process group is identified by the first process in the group ("process group leader"). ...
11
What's happening
When you press Ctrl+C, the SIGINT signal is delivered to the whole foreground process group. Here it's sent to both the find process and the calling shell process. find reacts by exiting immediately, and the shell reacts by calling the trap.
If the code in the trap returns (i.e. doesn't call exit), execution proceeds with the command after ...
10
Ctrl-Z does in fact stop the current foreground program, but it has nothing to do with the terminal emulator. It is handled by the shell you are currently running. The original shells for Unix didn't have this feature, so you might find that you are missing it on some systems, say a minimal embedded version of Linux booted into single user mode.
Ctrl-S ...
10
Ctrl+D, when typed at the start of a line on a terminal, signifies the end of the input. This is not a signal in the unix sense: when an application is reading from the terminal and the user presses Ctrl+D, the application is notified that the end of the file has been reached (just like if it was reading from a file and had passed the last byte).
Ctrl+C ...
10
Read its documentation. That's the only way. As Keith already wrote, the original meaning of SIGHUP was that the user had lost access to the program, and so interactive programs should die. Daemons — programs that don't interact directly with the user — have no need for this behavior and instead often reload their configuration files when they receive ...
10
Each signal has a "default disposition" -- what a process does by default when it receives that signal. There's a table in the signal(7) man page listing them:
Signal Value Action Comment
──────────────────────────────────────────────────────────────────────
...
SIGUSR1 30,10,16 Term User-defined signal 1
SIGUSR2 31,12,17 Term ...
10
No, you can't. From the xargs sources at savannah.gnu.org:
if (WEXITSTATUS (status) == CHILD_EXIT_PLEASE_STOP_IMMEDIATELY)
error (XARGS_EXIT_CLIENT_EXIT_255, 0,
_("%s: exited with status 255; aborting"), bc_state.cmd_argv[0]);
if (WIFSTOPPED (status))
error (XARGS_EXIT_CLIENT_FATAL_SIG, 0,
_("%s: stopped by signal %d"), ...
9
The process started by xterm will be the session leader in control of the terminal.
When the terminal goes away, that process automatically receive a SIGHUP signal (followed by a SIGCONT). This is sent by the kernel in a similar way that processes receive SIGINT when you press CTRL-C.
Additionally, a shell may send SIGHUP to some of its children upon ...
8
The signal(7) man page (at least the one I have) shows multiple possible numbers for some of the signals. If you can get kill to list the numbers, they should be correct for the running system. Try:
kill -l
or
kill -L
In both cases, that's an "ell" (for "list"), not a "one". Bash's built-in kill -l shows a nice numbered table. Linux's procps kill ...
8
Check the exit status of the command. If the command was terminated by a signal the exit code will be 128 + the signal number. For example if you interrupt a command with control-C the exit code will be 130, because SIGINT is signal 2 on Unix systems. So:
while [ 1 ]; do COMMAND; test $? -gt 128 && break; done
7
The default action is to terminate the process on SIGHUP. See man 7 signal for more details. But programs can trap it and do whatever they want. Since deamon processes are never supposed to exit they commonly use SIGHUP for other purposes, such as reinitializing themselves (as pppd does). Firefox keeps the default action.
6
Your second point lumps to completely different things together.
Ctrl+C sends a kill signal to the running process.
Ctrl+D sends an End of Transmission character.
You are looking for the latter.
6
To answer your second question first: SIGSTOP and SIGKILL cannot be caught by the application, but every other signal can, even SIGSEGV. This property is useful for debugging -- for instance, with the right library support, you could listen for SIGSEGV and generate a stack backtrace to show just where that segfault happened.
The official word (for Linux, ...
6
From the bash manual:
trap [-lp] [[arg] sigspec ...]
... If a sigspec is EXIT (0) the command arg is executed on exit from the shell.
6
sudo -u rswrk96 -i killall ... should be the same as doing su - rswrk96 and then killall ....
What's left is generating the sequence 00-96. This should work:
for i in $(seq -w 00 96); do sudo -u rswrk$i -i killall ...; done
Now that I think of it, you could probably just do
for i in $(seq -w 00 96); do sudo killall -u rswrk$i; done
Don't need to ...
6
The program sl purposely ignores SIGINT, which is what gets sent when you press Ctrl+C. So, firstly, you'll need to tell sl not to ignore SIGINT by adding the -e argument.
If you try this, you'll notice that you can stop each individual sl, but they still repeat. You need to tell bash to exit after SIGINT as well. You can do this by putting a trap "exit" ...
6
Historically, Unix had only these two signals, but modern systems have the real-time signals SIGRTMIN...SIGRTMAX.
Due to the wacky and unportable semantics of the signal APIs, there is almost no use case where signals would be preferrable over other communication mechanisms like pipes. Therefore, allocating a new signal number has never been seen as ...
6
What makes Ctrl-Z different from kill -STOP, and how can I get the behavior of the former in a shell script?
CTRL-Z usually sends SIGTSTP (which can be blocked), and apart form other things shells often reset tty to a previously saved state on these occasions. More importantly however, the controlling terminal process group is set to the shell's PID ...
6
Under Linux try man 7 signal.
kill -HUP 1234 means "send the SIGHUP signal (1) to process 1234", so it's equivalent to kill -1 1234. The default signal that is sent by kill is SIGTERM (15), so kill 1234 is equivalent to kill -TERM 1234 or kill -15 1234.
5
Summary: you're correct that receiving a signal is not transparent, neither in case i (interrupted without having read anything) nor in case ii (interrupted after a partial read). To do otherwise in case i would require making fundamental changes both to the architecture of the operating system and the architecture of applications.
The OS implementation ...
5
This is (somewhat) undefined.
If the receiving process is set up to take action upon receipt of the signal (that is, the signal is not ignored or blocked, then the process becomes runnable. If it has sufficient priority, then it is also scheduled immediately, but that is not guaranteed.
5
Something is taking a long time in one of your shell initialization files. Add set -x at the top of ~/.bash_profile or ~/.profile (or ~/.bash_login) if your login shell is bash, or ~/.zprofile and ~/.zlogin and ~/.zshrc if it's zsh. This way the shell will print each command before it executes it. Run set +x afterwards to turn the tracing off.
The command ...
Only top voted, non community-wiki answers of a minimum length are eligible
