Milter-greylist

Any word on this problem?

Jim 

> -----Original Message-----
> From: Jim Hermann - UUN Hostmaster [mailto:hostmaster@...] 
> Sent: Monday, September 04, 2006 08:38 AM
> To: 'milter-greylist@yahoogroups.com'
> Subject: Running milter-greylist in Debug Mode
> 
> When I run milter-greylist 2.0.2 in Debug Mode, it will 
> terminate after a while.
> 
> The last thing it displays on the terminal is:
> 
> Alarm clock
> 
> What does that mean?
> 
> Jim
> -----
> Jim Hermann <hostmaster@...>
> UUism Networks <http://www.UUism.net>
> Ministering to the Needs of Online UUs
> Web Hosting, Email Services, Mailing Lists
> -----
>

On Tue, Sep 05, 2006 at 07:40:48AM -0500, Jim Hermann - UUN Hostmaster wrote:
> Any word on this problem?

Never seen such a problem. Did you tried tracing it? Do you get a
SIGALRM? Anyone has an idea of where it comes from?

-- 
Emmanuel Dreyfus
manu@...

Emmanuel Dreyfus wrote:
 > Jim Hermann - UUN Hostmaster wrote:
 > > Any word on this problem?
 > 
 > Never seen such a problem. Did you tried tracing it? Do you get a
 > SIGALRM? Anyone has an idea of where it comes from?

It's the standard output of the default handler of SIGALRM
(just like "Segmentation fault" is the standard output from
SIGSEGV).  The exact format might depend on the OS and the
shell. For example, I can produce the output like this on
FreeBSD:

$ sleep 5 & kill -ALRM $!
[1]   Alarm clock             sleep 5

It usually only happens when there's a bug in a program,
such as when the programmer started a timer (e.g. using
setitimer()) but forgot to install a handler for SIGALRM.
Or the handler got lost or reset to the default, which
might happen when using signal() on systems that implement
the SystemV semantics (as opposed to BSD semantics), such
as Solaris.  You should better always use sigaction()
instead of signal() to avoid that problem.

Disclaimer:  I haven't looked at the milter-greylist code,
so I don't know if any of the above applies.  It was just
a generic explanation.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"A language that doesn't have everything is actually easier
to program in than some that do."
        -- Dennis M. Ritchie

On Tue, Sep 05, 2006 at 03:25:38PM +0200, Oliver Fromme wrote:
> It usually only happens when there's a bug in a program,
> such as when the programmer started a timer (e.g. using
> setitimer()) but forgot to install a handler for SIGALRM.
> Or the handler got lost or reset to the default, which
> might happen when using signal() on systems that implement
> the SystemV semantics (as opposed to BSD semantics), such
> as Solaris.  You should better always use sigaction()
> instead of signal() to avoid that problem.
> 
> Disclaimer:  I haven't looked at the milter-greylist code,
> so I don't know if any of the above applies.  It was just
> a generic explanation.

milter-greylist does not use timers, neither it uses signals.
Perhaps a problem in libmilter? 

-- 
Emmanuel Dreyfus
manu@...

On Tue, Sep 05, 2006 at 12:51:51PM +0000, Emmanuel Dreyfus wrote:
> On Tue, Sep 05, 2006 at 07:40:48AM -0500, Jim Hermann - UUN Hostmaster wrote:
> > Any word on this problem?
> 
> Never seen such a problem. Did you tried tracing it? Do you get a
> SIGALRM? Anyone has an idea of where it comes from?

Does it use sleep(3)? Some platforms implement that via SIGALRM.

	Kind regards

-- 
Matthias Scheler                                  http://zhadum.org.uk/

--- In milter-greylist@yahoogroups.com, Matthias Scheler <tron@...> 
wrote:
>
> On Tue, Sep 05, 2006 at 12:51:51PM +0000, Emmanuel Dreyfus wrote:
> > On Tue, Sep 05, 2006 at 07:40:48AM -0500, Jim Hermann - UUN 
Hostmaster wrote:
> > > Any word on this problem?
> > 
> > Never seen such a problem. Did you tried tracing it? Do you get a
> > SIGALRM? Anyone has an idea of where it comes from?
> 
> Does it use sleep(3)? Some platforms implement that via SIGALRM.
> 

Like this code from dump.c?

        for (;;) {
                /* XXX Not really dynamically adjustable */
                switch (conf.c_dumpfreq) {
                case -1:
                        sleep(DUMPFREQ);
                        break;

                case 0:
                        if ((error = pthread_cond_wait
(&dump_sleepflag,
                            &mutex)) != 0)
                            syslog(LOG_ERR, "pthread_cond_wait 
failed: %s\n",
                                strerror(error));
                        break;

                default:
                        sleep(conf.c_dumpfreq);
                        break;
                }

                /*
                 * If there is no change to dump, go back to sleep
                 */
                if ((conf.c_dumpfreq == -1) || (dump_dirty == 0))
                        continue;

                dump_perform();
        }