One possibility is that the program catches the Ctrl+C sequence. Check the output of stty -a; the intr setting indicates which key combination (if any) sends a SIGINT signal, and the isig indicates whether the signal keys are enabled (-isig means they are disabled).
If the program consists of several processes, pressing Ctrl+C sends SIGINT to all the processes in the process group. You can obtain the same effect by sending the signal to the process group instead of sending it to one of the processes. To send a signal to a process group, first determine its leader: that's the first process that starts all the others; if you run the process group in the background, that's the PID shown by jobs -l. The PID of the process group leader is the PGID (process group id); send the signal to its negative. E.g. if the PGID is 1234, run kill -INT -1234.
If the program consists of a wrapper script and a main application, there are two cases to consider. If there is no cleanup to do, so that the wrapper script terminates as soon as the main aplication terminates, make the wrapper script call exec:
#!/bin/sh
export SOMEVAR=somevalue
…
exec /path/to/application "$@"
This way the application replaces the script, inheriting its PID. Some shells optimize a script that ends by executing another program, but not all. This approach doesn't work when the script needs to perform some cleanup such as removing temporary files.
Consider making the script detect a signal and transmitting the signal to the application. Here's a sketch of how this goes:
/path/to/application "$@" &
app_pid=$!
trap -INT 'kill -INT $app_pid'
wait $!
rm /temp/file
Generally services keep the log files opened while they are running. This mean that they do not care if the log files are renamed/moved or deleted they will continue to write to the open file handled.
When logrotate move the files, the services keep writing to the same file.
Example:
crond will write to /var/log/cron.log. Then logrotate will rename the file to /var/log/cron.log.1, so crond will keep writing to the open file /var/log/cron.log.1.
Sending the HUP signal to crond will force him to close existing file handle and open new file handle to the original path /var/log/cron.log which will create a new file.
The use of the HUP signal instead of another one is at the discretion of the program. Some services like php-fpm will listen to the USR1 signal to reopen it's file handle without terminating itself.
Best Answer
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
sigactioncalls that set up a signal handler forSIGHUP, 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. withps son 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.