Hot answers tagged

219

All modern CPUs have the capacity to interrupt the currently-executing machine instruction. They save enough state (usually, but not always, on the stack) to make it possible to resume execution later, as if nothing had happened (the interrupted instruction will be restarted from scratch, usually). Then they start executing an interrupt handler, which is ...


67

Under Linux, you can find the PID of your process, then look at /proc/$PID/status. It contains lines describing which signals are blocked (SigBlk), ignored (SigIgn), or caught (SigCgt). # cat /proc/1/status ... SigBlk: 0000000000000000 SigIgn: fffffffe57f0d8fc SigCgt: 00000000280b2603 ... The number to the right is a bitmask. If you convert it from hex ...


56

press Ctrl-Z to suspend the script kill %% The %% tells the bash built-in kill that you want to send a signal (SIGTERM by default) to the most recently suspended background job in the current shell, not to a process-id. You can also specify jobs by number or by name. e.g. when you suspend a job with ^Z, bash will tell you what its job number is with ...


45

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 ...


39

The shell does indeed have something to do with that message, and crsh indirectly calls a shell, which is probably bash. I wrote a small C program that always seg faults: #include <stdio.h> int main(int ac, char **av) { int *i = NULL; *i = 12; return 0; } When I run it from my default shell, zsh, I get this: 4 % ./segv ...


36

After the first Ctrl-C, the program will receive SIGINT and usually starts cleaning up (deleting tmp files, closing sockets, etc.). If you hit Ctrl-C again while that is going on, it may happen that you interrupt the clean up routine (i.e. the additional signal might be acted upon instead of being left alone), leaving a mess behind. While this usually is not ...


33

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 ...


33

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" ...


33

On Linux it depends on the file capabilities. Take the following simple mykill.c source: #include <stdio.h> #include <sys/types.h> #include <signal.h> #include <stdlib.h> void exit_usage(const char *prog) { printf("usage: %s -<signal> <pid>\n", prog); exit(1); } int main(int argc, char **argv) { ...


29

Processes can call the exit() system call (on Linux, they are rather called _exit() or exit_group()) with an integer argument to report an exit code to their parent. Though it's an integer, only the 8 least significant bits are available to the parent (exception to that is when using waitid() in the parent to retrieve that code, though not on Linux). The ...


28

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 ...


27

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 ...


26

It depends on the OS buffers and the timing between the 10th and 11th writes of dmesg. After head writes 10 lines, it terminates and dmesg will receive SIGPIPE signal if it continues writing to the pipe. Depending on your OS buffer, dmesg will often write more than 10 lines before head consumes them. To see that head had consumed more than 10 lines, you ...


23

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 ...


23

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 ...


23

Nothing: strace kill -HUP 1 [...] kill(1, SIGHUP) = -1 EPERM (Operation not permitted) [...]


22

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 ...


22

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 ...


21

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 ...


20

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 ...


20

I think you may be confused about the job control notation. Notably "Stopped" means that a job is still alive but that its ability to process anything has been held (it is not given any time on the CPU to process anything). This is effectively a 'Pause' or 'Suspended' state, although that is not the correct technical term. CtrlC does not "stop" a job, it ...


20

Try: #!/bin/bash _term() { echo "Caught SIGTERM signal!" kill -TERM "$child" 2>/dev/null } trap _term SIGTERM echo "Doing some initial work..."; /bin/start/main/server --nodaemon & child=$! wait "$child" Normally, bash will ignore any signals while a child process is executing. Starting the server with & will background it into the ...


19

Check the exit status of the command. If the command was terminated by a signal the exit code will be 128 + the signal number. From the GNU online documentation for bash: For the shell’s purposes, a command which exits with a zero exit status has succeeded. A non-zero exit status indicates failure. This seemingly counter-intuitive scheme is used so ...


19

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"), ...


19

On Solaris, run psig on the process id to get a list of signals and how they'll be handled. For instance: bash-4.2$ psig $$ 11088: bash HUP caught termsig_sighandler 0 HUP,INT,ILL,TRAP,ABRT,EMT,FPE,BUS,SEGV,SYS,PIPE,ALRM,TERM,USR1,USR2,VTALRM,XCPU,XFSZ,LOST INT caught sigint_sighandler 0 QUIT ignored ILL caught termsig_sighandler 0 ...


19

In ssh host tail -f file The ssh client connects to the sshd server on host over a TCP connection. sshd runs tail -f with its stdout redirected to a pipe. sshd reads what's coming from the other end of the pipe and encapsulates it in the sshd protocol to send to the ssh client. (with rshd, tail stdout would have been the socket directly, but sshd adds ...


19

It is because of NPTL. Since it is part of the GNU C library nearly every modern linux distribution don't uses the first two real time signals anymore. NPTL is an implementation of the POSIX Threads. NPTL makes internal use of the first two real-time signals. This part of the signal manpage is very interesting: The Linux kernel supports a range of 32 ...


19

The exit status of a killed command should be the signal number plus 128. So you can use the exit status to find out which signal killed you process. I tested it like this on Linux in the shell: print_exit_status_for_signal () { ( sleep 1000 echo Exit staus $? = signal $(( $? - 128 )) ) & sleep 1 killall "${1:+-$1}" sleep } ...


18

I can't seem to find any information on this aside from "the CPU's MMU sends a signal" and "the kernel directs it to the offending program, terminating it". This is a bit of a garbled summary. The Unix signal mechanism is entirely different from the CPU-specific events that start the process. In general, when a bad address is accessed (or written to a ...


17

Take a look at the POSIX specification for the write() function: The write() function shall fail if: … An attempt is made to write to a pipe or FIFO that is not open for reading by any process, or that only has one end open. A SIGPIPE signal shall also be sent to the thread. So the sequence of events is: The head process exits. This causes all ...



Only top voted, non community-wiki answers of a minimum length are eligible