Professional Web Applications Themes

How does nohup work? Can a program override it? - UNIX Programming

I have a program that installs a signal handler for SIGHUP, which causes the program to exit gracefully. When I run that program from a Makefile thusly: $(EXE).pid: ./$(EXE) nohup ./$(EXE) & echo $$! > $(EXE).pid I would expect it not to catch SIGHUP, but it does. Why is that? -SEan...

  1. #1

    Default How does nohup work? Can a program override it?


    I have a program that installs a signal handler for SIGHUP,
    which causes the program to exit gracefully. When I run that
    program from a Makefile thusly:

    $(EXE).pid: ./$(EXE)
    nohup ./$(EXE) & echo $$! > $(EXE).pid

    I would expect it not to catch SIGHUP, but it does.
    Why is that?

    -SEan
    Sean Guest

  2. #2

    Default Re: How does nohup work? Can a program override it?

    man nohup.

    C3


    C3 Guest

  3. #3

    Default Re: How does nohup work? Can a program override it?

    Sean Burke <org> wrote:
     
     
     

    And it catches SIGHUP when you do ... what?

    --
    Hans-Bernhard Broeker (rwth-aachen.de)
    Even if all the snow were burnt, ashes would remain.
    Hans-Bernhard Guest

  4. #4

    Default Re: How does nohup work? Can a program override it?


    Hans-Bernhard Broeker <rwth-aachen.de> writes:
     


    >
    > And it catches SIGHUP when you do ... what?[/ref]

    I don't do anything, except execute the makefile.
    I believe the SIGHUP is generated when the shell
    that make uses to run the rule action exits.

    At least, that is what I think is happening.

    -SEan


    Sean Guest

  5. #5

    Default Re: How does nohup work? Can a program override it?

    "Sean Burke" <org> wrote in message
    news:xenadyne.com... 
    > > 
    > > 
    > >
    > > And it catches SIGHUP when you do ... what?[/ref]
    >
    > I don't do anything, except execute the makefile.
    > I believe the SIGHUP is generated when the shell
    > that make uses to run the rule action exits.
    >[/ref]

    What shell are you using on what OS? There are some shell
    implementations that routinely send SIGHUP to any running program.

    Norm

    Norm Guest

  6. #6

    Default Re: How does nohup work? Can a program override it?

    On Thu, 05 Feb 2004 22:12:29 +0000, Sean Burke wrote:
     

    The core function of nohup(1) is to perform the equivalent of

    signal( SIGHUP, SIG_IGN );

    prior to executing the named program. If a signal is being ignored that
    status is propagated across fork() and exec(). But the new process is free
    to reset the signal to SIG_DFL (i.e., the system default action for the
    signal) or to install its own handler.

    There's nothing magical about nohup(1). It simply provides a convenient
    means of exempting processes started from an interactive shell from the
    SIGHUP normally generated by the "tty" driver and top-level shell when the
    session is ended. Without such a command you'd have to use crontab(1),
    at(1), or a similar command to execute the job. Of course I've glossed
    over lots of detail, such as exactly which processes get the SIGHUP.
    Research "job control shells" and "POSIX job control" for the details.
    Kurtis Guest

  7. #7

    Default Re: How does nohup work? Can a program override it?


    "Kurtis D. Rader" <us> writes:
     
    >
    > The core function of nohup(1) is to perform the equivalent of
    >
    > signal( SIGHUP, SIG_IGN );
    >
    > prior to executing the named program. If a signal is being ignored that
    > status is propagated across fork() and exec(). But the new process is free
    > to reset the signal to SIG_DFL (i.e., the system default action for the
    > signal) or to install its own handler.[/ref]

    Which is what my process did.
     

    OK, that makes sense. I did have the idea that nohup would do
    something "magical" with process groups to prevent the shell
    from sending SIGHUP to my process.

    Thanks.
    -SEan

    Sean Guest

  8. #8

    Default Re: How does nohup work? Can a program override it?


    "Norm Dresner" <net> writes:
     
    > >
    > > I don't do anything, except execute the makefile.
    > > I believe the SIGHUP is generated when the shell
    > > that make uses to run the rule action exits.
    > >[/ref]
    >
    > What shell are you using on what OS? There are some shell
    > implementations that routinely send SIGHUP to any running program.[/ref]

    This is gmake on Solaris, so I assume it uses /bin/sh
    to run the rule actions. It looks like Kurtis Rader's
    explanation is correct - I didn't realize that processes
    inherit ignored signals from parents, and that that is
    how nohup works. My program installed a signal handler
    for SIGHUP, undoing the effect of nohup.

    -SEan


    Sean Guest

  9. #9

    Default Re: How does nohup work? Can a program override it?

    On Sat, 07 Feb 2004 22:09:33 +0000, Sean Burke wrote:
     

    By the way, I suspect you've already figured this out, but it is wrong for
    a process to catch SIGHUP except in very limited cirstances. For
    example, the process deliberately performs the steps necessary to become a
    "daemon" and wishes to use SIGHUP as a means of signifying it should
    reread its configuration data. Of course, in that case the SIGHUP
    generated by the "tty" driver and login shell won't ever reach the
    process. Another case is where the process should basically never run as a
    "daemon" and wants to ensure it terminates cleanly if spawned from an
    interactive shell and the session is terminated.

    On a related note, I frequently see programs with code like the following
    in their initialization routine:

    #ifndef NSIG
    #define NSIG 32
    #endif
    for( i = 0; i < NSIG; i++ ) {
    signal( i, sig_catcher );
    }

    IMHO, this is fubar. A program should only catch signals for which it is
    prepared to take some sort of action other than simply printing "killed by
    signal #n".
    Kurtis Guest

  10. #10

    Default Re: How does nohup work? Can a program override it?

    "Kurtis D. Rader" <us> writes:
     

    Indeed; nothing more infuriating than a backgrounding a long running
    job using "^Z bg" only to find it prints "killed by signal 24".

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  11. #11

    Default Re: How does nohup work? Can a program override it?


    "Kurtis D. Rader" <us> writes:
     
    >
    > By the way, I suspect you've already figured this out, but it is wrong for
    > a process to catch SIGHUP except in very limited cirstances. For
    > example, the process deliberately performs the steps necessary to become a
    > "daemon" and wishes to use SIGHUP as a means of signifying it should
    > reread its configuration data. Of course, in that case the SIGHUP
    > generated by the "tty" driver and login shell won't ever reach the
    > process.[/ref]
     

    Yes, that was the idea here - to ensure a graceful termination
    when running as a background process and the shell exits.

    I guess that if you want to catch SIGHUP, and still work with
    nohup in the expected way, you should do:

    sighold(SIGHUP);
    if (signal(SIGHUP, set_quit) == SIG_IGN)
    sigignore(SIGHUP);
    sigrelse(SIGHUP);

    -SEan




    Sean Guest

  12. #12

    Default Re: How does nohup work? Can a program override it?

    On Mon, 09 Feb 2004 00:44:28 +0000, Sean Burke wrote:
     

    Note that sighold(), et. al., are AT&T SysV'isms. If portability of your
    code matters then it's arguably better to use the POSIX sigprocmask()
    function. And you should never use signal(). It's broken by design. Either
    use sigaction() or sigset(). Of course, if you don't care about signal
    delivery race conditions then by all means use signal() :-)

    Lastly, the code sequence you show, while correct, is unecessary. Any
    program that is designed to be a "daemon", and for which such a sequence
    might be appropriate, should simply become a daemon. Once the proper
    sequence of function calls to become a daemon has been executed it is
    immaterial whether or not SIGHUP was ignored by the parent process and the
    process can simply install its own SIGHUP handler. If the program isn't
    expected to run as a daemon detached from a controlling tty then it
    shouldn't install a SIGHUP handler in the first place.
    Kurtis Guest

Similar Threads

  1. Program doesn't work
    By David in forum Windows Vista
    Replies: 9
    Last Post: April 27th, 09:03 AM
  2. nohup stdout
    By sukhpreet in forum Linux / Unix Administration
    Replies: 1
    Last Post: August 4th, 03:17 PM
  3. nohup received the Hangup signal...
    By Fitzmaurice,Jamie in forum AIX
    Replies: 3
    Last Post: November 12th, 07:40 PM
  4. cout/printf in nohup.out
    By qazmlp in forum UNIX Programming
    Replies: 2
    Last Post: July 20th, 09:34 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139