Program behavior when kill -HUP is recieved?

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 SIGHUP. But these are just conventions.

If you have the source, you can read that, too. Or if you only have the binary, you can try disassembling it, look for sigaction calls that set up a signal handler for SIGHUP, and try to figure out what those signal handlers are doing. It'll be easier arranging not to send SIGHUP to that program in the first place.

At any point in time, a given process is in one of three states with respect to a particular signal: ignoring it, performing the default action or running a custom handler. Many unices allow you to see the signal mask of a process with ps, e.g. with ps s on Linux. That can tell you if the process is ignoring the signal or will die instantly on SIGHUP, but if the process has set a handler you can't tell what the handler does.


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

Tags:

Signals

Kill