simple daemon dies

simple daemon dies

[Sindunata]

Hi all,

I'm trying to write a simple daemon background process.
It connects to PostgreSQL and wait for a notify event and upon receiving
some event will invoke some URL using curl library.

I got it working already if I run it in foreground. But if I put the
process in background (using &), and then after sometime the process
will die. I think there's some signal that I need to catch, can
someone please help me?

Currently i'm trapping the following signals:

  struct sigaction act;
  
  /* set signal handler TERM (terminate by kill) & INT (keyboard break) to exit nicely */
  act.sa_flags = 0;
  act.sa_handler = mainExit;
  sigemptyset (&(act.sa_mask));
  
  sigaction (SIGTERM, &act, NULL);
  sigaction (SIGINT, &act, NULL);

  /* ignore SIGHUP  & SIGTTOU */
  act.sa_handler = SIG_IGN;
  sigaction(SIGHUP, &act, NULL);
  sigaction(SIGTTOU, &act, NULL);

TIA & regards,
Sindu

Re: simple daemon dies

[Glynn Clements]

Sindunata wrote:

> I'm trying to write a simple daemon background process.
> It connects to PostgreSQL and wait for a notify event and upon receiving
> some event will invoke some URL using curl library.
> 
> I got it working already if I run it in foreground. But if I put the
> process in background (using &), and then after sometime the process
> will die.

In which case, the shell will tell you why it died.

Exited normally with zero status:

	[1]+  Done                    prog

Exited normally with non-zero status:

	[1]+  Exit 1                  prog

Terminated due to SIGTERM:

	[1]+  Terminated              prog

Terminated due to SIGIOT (aka SIGABRT):

	[1]+  Aborted                 (core dumped) prog

Terminated due to SIGKILL:

	[1]+  Killed                  prog

... and so on.

> I think there's some signal that I need to catch, can
> someone please help me?

You don't necessarily *need* to catch any signals. Most of the signals
which terminate a process (e.g. SIGHUP, SIGTERM, SIGINT) are *meant*
to terminate the process. When a program catches one of these signals,
it's normally so that it can "clean up" before it terminates, not to
prevent termination altogether.

> Currently i'm trapping the following signals:

>   sigaction (SIGTERM, &act, NULL);
>   sigaction (SIGINT, &act, NULL);

These are meant to kill the process; there's no reason to catch them.

>   /* ignore SIGHUP  & SIGTTOU */
>   act.sa_handler = SIG_IGN;
>   sigaction(SIGHUP, &act, NULL);

Same here.

>   sigaction(SIGTTOU, &act, NULL);

This will only stop the process, not terminate it.

If you're trying to write a daemon (as opposed to simply running in
the background), the process should be entirely disassociating itself
from the terminal and from the process group, so it shouldn't be
affected by terminal-related signals.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: simple daemon dies

[Sindunata]

Hi Glynn & All,

Thanks for the explanation. I found the bug in my code:
  printf("%s", CURLreturn);
while it should be
  printf("%d", CURLreturn);

This cause a segmentation fault. Anyway when I tried running it in the
background and disconnect my terminal, it seems good now.

> You don't necessarily *need* to catch any signals. Most of the signals
> which terminate a process (e.g. SIGHUP, SIGTERM, SIGINT) are *meant*
> to terminate the process. When a program catches one of these signals,
> it's normally so that it can "clean up" before it terminates, not to
> prevent termination altogether.

Yupe, I'm catching those signals (SIGTERM & SIGINT) to cleanly and
politely :) disconnecting from postgresql only.

> >   /* ignore SIGHUP  & SIGTTOU */
> >   act.sa_handler = SIG_IGN;
> >   sigaction(SIGHUP, &act, NULL);
> 
> Same here.
>
> >   sigaction(SIGTTOU, &act, NULL);
> 
> This will only stop the process, not terminate it.

I tought that I need to ignore SIGHUP & SIGTTOU so that my process is
not killed/stopped when I disconnect my terminal. CMIIW.

> If you're trying to write a daemon (as opposed to simply running in
> the background), the process should be entirely disassociating itself
> from the terminal and from the process group, so it shouldn't be
> affected by terminal-related signals.

This is exactly what I'd like to do, writing a daemon. I tought that
it's just a normal C program which catches some signal. I'm still a
novice in linux C programming. Perhaps someone would give me examples how
to disassociate from the terminal and process group.

TIA & best regards,
Sindu

Re: simple daemon dies

[Glynn Clements]

Sindunata wrote:

> > >   /* ignore SIGHUP  & SIGTTOU */
> > >   act.sa_handler = SIG_IGN;
> > >   sigaction(SIGHUP, &act, NULL);
> > 
> > Same here.
> >
> > >   sigaction(SIGTTOU, &act, NULL);
> > 
> > This will only stop the process, not terminate it.
> 
> I tought that I need to ignore SIGHUP & SIGTTOU so that my process is
> not killed/stopped when I disconnect my terminal. CMIIW.

OK; SIGHUP will kill it, SIGTTOU will stop (suspend) it.

This is normally the desired behaviour for "user" programs. For a
daemon, disassociating from the controlling terminal ensures that you
don't get these signals, so you don't need to handle them.

> > If you're trying to write a daemon (as opposed to simply running in
> > the background), the process should be entirely disassociating itself
> > from the terminal and from the process group, so it shouldn't be
> > affected by terminal-related signals.
> 
> This is exactly what I'd like to do, writing a daemon. I tought that
> it's just a normal C program which catches some signal. I'm still a
> novice in linux C programming. Perhaps someone would give me examples how
> to disassociate from the terminal and process group.

Stevens[1] gives this topic (daemon processes) its own chapter,
although the basics are:

1. Call fork(), and have the parent call exit(). This puts the command
into the background, and also ensures that it isn't a process group
leader.

2. Call setsid() to create a new session (it will also create a new
process group). The process will be the session leader, and also the
process group leader of the new process group. Furthermore, it will
have no controlling terminal, so the various terminal signals are no
longer relevant.

3. Either chdir() to a specific working directory (e.g. printer
daemons may chdir() to their spool directory), or chdir() to the root
directory. This ensures that the process doesn't inadvertently prevent
a filesystem from being unmounted.

4. If the daemon will create any files, call umask() to set the umask
to a suitable value (rather than whatever value it happened to
inherit).

5. Close all descriptors. Keeping inherited descriptors open may
interfere with other processes which share them (e.g. a socket isn't
closed until every process has closed the descriptor). This isn't
entirely straightforward, as there isn't a reliable way of determining
the maximum descriptor number. OTOH, calling close() on a non-existent
descriptor is harmless.

Also, specify O_NOCTTY when opening anything which might be a
terminal. Opening a terminal without this flag will cause it to become
the process' controlling terminal, which you probably don't want.

[1] Advanced Programming in the Unix(R) Environment
    W Richard Stevens
    Addison-Wesley

-- 
Glynn Clements <glynn.clements@virgin.net>