topic Re: the process terminated after kill –HUP signal in Operating System - Linux

the process terminated after kill –HUP signal

bullz — Fri, 16 Jul 2010 03:32:54 GMT

Hey all,

As far as I am aware, the command kill –HUP will not be terminating the process. Just it will try to re read the configuration files.
But, recently when I faced the LSOF ( list of open files ) issue, to clear the file system utilization issue, I tried restart the tomcat process by kill –HUP

Unfortunately, the process terminated after kill –HUP signal

Could you please share your experience on the issue?

Re: the process terminated after kill –HUP signal

Kapil Jha — Fri, 16 Jul 2010 04:03:38 GMT

A process that usually starts when the system boots and shuts down when the system is shut down is called a daemon (Disk And Execution MONitor). If a daemon process has a configuration file which is modified after the process has been started, there should be a way to tell that process to re-read its configuration file, without stopping the process. Many daemons provide this mechanism using the SIGHUP signal handler. When you want to tell the daemon to re-read the file you simply send it the SIGHUP signal.

Not all platforms automatically reinstall their (native) signal handlers after a signal delivery. This means that the handler works only the first time the signal is sent. The solution to this problem is to use POSIX signal handlers if available, their behaviour is well-defined.

http://theoryx5.uwinnipeg.ca/CPAN/perl/pod/perlipc/handling_the_sighup_signal_in_daemons.html

from man kill
--------------
1 SIGHUP Hangup Terminate; can be trapped
-------------

You have to make it understand the signals.

BR,
Kapil+

Re: the process terminated after kill –HUP signal

Goran Koruga — Fri, 16 Jul 2010 04:10:44 GMT

Hello.

As already explained, the default action for SIGHUP is "Terminate" (see 'man 7 signal').

Do not think of SIGHUP as a generic way to restart processes, only a small number of processes actually do this.

It's probably better to use its init script to restart it.

Regards,
Goran

Re: the process terminated after kill –HUP signal

Steven Schweda — Fri, 16 Jul 2010 04:25:32 GMT

Some programs are written so that they do
something useful when they get a HUP signal,
and some are not. It's often a good idea to
learn what a program is designed to do when
it gets some signal _before_ you send it that
signal.

Re: the process terminated after kill –HUP signal

Matti_Kurkela — Fri, 16 Jul 2010 09:33:35 GMT

The original purpose of the "kill -HUP" signal was to tell user's processes that the user's dial-in modem connection has been lost. Most user utilites will just die; editors like vi are often programmed to save any modified files in a special location, so that the user does not lose the changes made before the loss of connection. Shell processes will typically execute a logout procedure when they receive the "kill -HUP" signal.

When the modem connection was lost, the HUP signal was sent by the tty driver to all processes using that TTY. Later, the meaning of the HUP signal was generalized to "we've lost the connection with the user, end this login session."

Daemon processes are normally detached from all TTYs, so the loss of login session is not an issue for them. At some point, the early Unix developers decided to re-use the HUP signal to trigger a configuration re-load for daemon processes. Not all daemons can reload their configuration on the fly, and some daemons (particularly Java daemons like Tomcat) may require a different kind of message for configuration reload.

The HUP signal never causes anything to _restart_: if the daemon's PID number changes when a "kill -HUP" is sent to it, it usually means that the HUP signal just kills the daemon, and then something else (maybe init, maybe some other monitoring process?) restarts the daemon.

You should never assume that "kill -HUP" will reload a daemon's configuration without checking the daemon's documentation first.

MK

Re: the process terminated after kill –HUP signal

bullz — Wed, 24 Nov 2010 07:05:27 GMT

Thanx