Tag Info

Hot answers tagged

44

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


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

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


26

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


22

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


21

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


20

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


16

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


15

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


15

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


14

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


14

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


14

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


14

You get the PID with PID=$$. What you want may be most easily achieved with the command timeout. But you can run a background process, too: (sleep $TIMEOUT && kill "$PID") &


14

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


13

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


13

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


13

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


13

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


13

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


13

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. The parent will typically do a wait() or waitpid() to get the status of their child as an integer. On ...


12

The timeout utility that is a part of GNU coreutils does it for you: timeout 5m bash script.sh would terminate the script after 5 minutes of execution.


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


11

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


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

You should start with the gentlest one and escalate from there. This means, SIGINT, SIGTERM, SIGQUIT, SIGKILL. Although most people skip SIGINT and SIGQUIT.


10

I generally just hold down Ctrl-C. Sooner or later it'll register between COMMAND's and thus terminate the while loop. Maybe there is a better way.


10

You're wasting them. All that happens is that once the server finishes with the screen output, it will receive multiple Ctrl-C. The first one will be used to kill the process, and the following ones will end up in your shell, which will then look something like [user@server]$ ^C [user@server]$ ^C [user@server]$ ^C [user@server]$ ^C [user@server]$ ^C ...


9

From the bash manual: trap [-lp] [[arg] sigspec ...] ... If a sigspec is EXIT (0) the command arg is executed on exit from the shell.



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