Bugga.NET

kill -HUP $pid and when to use it

—

by

malliemcg
in

kill -HUP $pid sends a SIGHUP to the process with the process id $pid.

This is useful for telling programs that listen for a HUP to re-read their configuration files so that you can seamlessly implement changes transparent to end users. Not all programs will re-read their config files when they recieve a SIGHUP .

You can? also tell a program to ignore a SIGHUP, this can be useful if you want to start a background job from a terminal and close that terminal window (ie: wget, or a daemon/server process that you are debugging) as terminals will send a SIGHUP when you close them.

Comments

One response to “kill -HUP $pid and when to use it”

  1. jim Avatar
    jim

    Probably stuff that you’re already aware of, but someone else may find this helpful.

    A little background… The HUP is short for Hang UP. Back in the dim dark ages when we dialed into Unix systems via a modem, or dumb terminal, the HUP signal was used to signal to all of the processes in the user’s login session that the user had disconnected (i.e. the modem had Hung UP). Most processes took this as a sign that they should exit, becuase if the user had disconnected there was little point thier remaining active.

    Sidebar: This is why the “nohup” command is used to indicate to the kernel that a process should continue after the user logs out (it indicates to the kernal that the process should not receive the HUP signal, hence the name). To use nohup, simply prefix the command you want to keep running with “nohup” e.g. “nohup tail -f /var/log/messages”.

    Now, how a process handles the HUP signal is up to the programmer who wrote the code for the process, remember HUP indicates that the user session has ended, but how the app responds to the signal is up to the process author. This is in contrast to the kill signal for example, where it is recommended that the process terminates itself as quickly as possible.

    Generally daemon processes run independently of a perticular user’s login session, and as background processes on a machine. They’re not tied to a particular login session, and so they’ll never receive a HUP signal in normal operation. However, because daemons are often running for a long period of time, and a full stop/start isn’t always desirable, a method of signalling to the daemon that it should re-read its config file is useful.

    Hence we have a situation where we need to signal a daemon to re-read its config, and a signal which all Unices support, and no daemon will ever see in normal operation. THe obvious solution? Co-opt the HIP signal to indicate that a daemon should re-read its config, and this is exactly what most modern daemons will do when they receive a HUP signal.

    Thus we arrive at the situation we have today where many processes will exit when HUP’ed, and daemons will instead re-read their config files.

Leave a Reply