SIGHUP or HUP signal

[Lacrosse]

I am trying to recall the syntax we used to fix a Zombie problem years ago. It involved using the -sighup switch on the startup command for a unidata process in the profile. This prevented the process from spinning off into a zombie when the user dropped off abnormally.....can someone refresh my memory a tell me what the signal was -hup -nohup
-sighup and what was happening here

[Jeff Schussele]

Hi,

Number one rule of Zombies - "You can't kill - they're already dead!"

They will eventually be reaped by the OS.

If you're ending up with loads of them, then you need to determine why & fix that. Rule two - the child should be reaped when the parent dies - else it's coded wrong.

To run something so that when the parent exits it remains, then
nohup command [args]
would be the syntax.

Rgds,
Jeff

Rgds,
Jeff

[Steven E. Protter]

The only success I've ever had with zombies is kill -9

kill it and its parents.

Not much success at that btw.

SEP

[Kenneth Platz]

Are you sure you're not referring to "nohup"?

Ie,

nohup cmd_name &

Will run the command in the background, and will trap the "HUP" signal so it doesn't zombie-fy?

[Pete Randall]

Hey Hookem!

By definition, zombies do not respond to signals. That means that hup, sighup, sigkill (-9) will have no effect. What you want to do is to nohup the process.


Pete

[Lacrosse]

I think Ken had the answer to clarify my question the nohup would prevent them from becoming zombies

[Bill Hassell · Accepted solution]

man kill (or kill -l to list the signals)


kill -1 or kill -hup (or kill -HUP) will send the hangup signal to a process. The signal's purpose is to notify a program that the connection has been terminated as in a modem hangup. Apparently Unidata doesn't handle this signal without special startup options. You can test to see whether the signal works correctly by using the kill -hup command.

Zombies as Jeff mentioned, are already dead and are caused by bad coding in the parent program. A parent is responsible for all child processes (interesting metaphor...) and must not abandon a child. It must wait until the child terminates, or passes control of the child's termination to init.

nohup is a protector, nothing else. It simply intercepts the SIGHUP signal and throws it away. This would be needed if you started a long process that ran for 5 hours and you wanted to logout and let the process run by itself. The & (background) syntax puts the program into a separate queue but as soon as the parent (typically a shell) exits, it will terminate all children with a SIGHUP. Thus, nohup process_name & will place the program into the background AND ignore the parent's exit. The background process is then assigned to init which performs the proper cleanup of a terminating child.