Subject: [Dev] Re: simple daemon dies

From: "John F Davis" <[email-masked]>
Date: Wed, 29 May 2002 14:12:57 -0400

Hello

I thought this would be interesting to those who followed the "Re: [Dev]
HOWTO write a daemon" thread.

JD
---------------------- Forwarded by John F Davis/Raleigh/IBM on 05/29/2002
02:10 PM ---------------------------

Glynn Clements <[email-masked]>@vger.kernel.org on 05/29/2002
05:29:36 AM

Sent by:    [email-masked]

To:    Sindunata <[email-masked]>
cc:    [email-masked]
Subject:    Re: simple daemon dies

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 <[email-masked]>
-
To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
the body of a message to [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

---

From: "Peter Long" <[email-masked]>
Date: Thu, 30 May 2002 00:25:38 -0400 (EDT)

> Hello
> 
> I thought this would be interesting to those who followed the "Re:
> [Dev] HOWTO write a daemon" thread.
> 
<snip>

Interesting reading. I got my little daemon working in about 1 hour thanks 
to all the advice given here. The only signal I am handling is SIGQUIT. I 
use it to set a flag that causes all the worker threads in my daemon to 
exit. It works perfectly.

I was wondering if there is a template out there showing a reference 
implementation of signal handlers? If seems dangerous to just let the 
default handler handle all signals. Does that not mean SIGTERM would zap 
your process without giving you a chance to free file handles, close 
sockets of whatever?

-- 
Peter Long
mailto:[email-masked]

---

From: Michael Mueller <[email-masked]>
Date: Thu, 30 May 2002 09:09:48 -0400

On Thursday 30 May 2002 00:25, Peter Long reputedly wrote:
<snip> The only signal I am handling is SIGQUIT. I
> exit. It works perfectly.

What happens when the the daemon is abruptly killed?   Happy ending with a 
clean restart?
> your process without giving you a chance to free file handles, close

My experience with the default handlers are positive.  I have systems that 
have been running for months that have endured repeated ungraceful endings to 
my multi-daemon application.  I have a script to kill all the remaining 
daemons. I prefer to have a manual cleanup so I can analyse the "crime 
scene".   

There's one nagging problem I can use some help with.  When I run in 
foreground and get a segmentation fault, there is a nice message alerting me 
to this event.  When my daemons hit a seg. fault there's no indication in 
/var/log/messages.  Any hints on how to find clues that a daemon did a seg. 
fault would be most appreciated.
-- 
Mike Mueller
www.ss7box.com

---

From: "Peter Long" <[email-masked]>
Date: Thu, 30 May 2002 22:31:04 -0400

----- Original Message -----
From: "Michael Mueller" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 30, 2002 9:09 AM
Subject: Re: [Dev] Re: [Dev] Re: simple daemon dies

> What happens when the the daemon is abruptly killed?   Happy ending with a
I am not 100% sure what you are asking? When you say "killed abruptly"  do
you mean with SIGKILL(-9)?
In my case the default behaviour (to terminate the process) would abort any
open tcp connections. I would prefer to shut them down gracefully. It
restarts cleanly after being killed.

Looking at man 7 signal it says that the default behaviour for SIGQUIT (-3)
is to terminate and dump core. I do not do that, I just terminate. I guess I
should rather catch SIGTERM (-15) since it can be caught where as SIGKILL
cannot. Its default behaviour is to terminate the process.

> fault would be most appreciated.

Again according to man 7 signal, SIGSEGV is signaled when a segmentation
fault occurs. I wonder if you could catch it and then try extract some
usefull information from the system. At the very least you could log the
fact that is occured.

--
Peter Long

---

From: Mike McLean <[email-masked]>
Date: Thu, 13 Jun 2002 16:39:05 -0400

> usefull information from the system. At the very least you could log the

You can indeed catch SIGSEGV.  The only signals that cannot be caught 
are SIGKILL and SIGSTOP.