Definitely! AUTOREVIEW ON is very dangerous. It was intended as a fix for messages that land in Review from a restart or crash, however if there is a killer message it will get moved back to Proc immediately and cause crashes over and over again. Declude could do this much better by detecting what caused the GPF and only moving those files to Review...but they don't.

The workaround for both issues is to script a task that runs every 30 minutes which will move all files from Review back to Proc. This way if there is a killer message, it will only affect you once every 30 minutes, and a declude system can easily survive that. One can do a better job with the scripting to even detect repeated crashes on the same file so as to avoid them, but this works well enough in most cases since most messages that cause crashes will go through on a second try. Here's the code that you want to package up in a CMD file and run under Task Scheduler once every 30 minutes (customize for your paths):

   MOVE /Y F:\proc\review\*.* F:\proc

Matt



Colbeck, Andrew wrote:
In my declude.cfg I have set the:
AUTOREVIEW OFF which is the default for this directive. I've seen a "poison email" that makes Declude crash or stop quietly, and AUTOREVIEW ON just puts the poison email back in the queue again. You may find that there are c:\declude.gp1 and c:\declude.gp2 files on your crashed system, with corresponding decMMDD.log entries. I'm not entirely sure if the cause is actually the same, but I've also seen two Declude systems that were hosed by too much traffic; there were literally over a hundred CSCRIPT.EXE and SNIFFER.EXE child processes orphaned with each orphan allocated only 48KB in Task Manager. I've only ever seen that particular orphan behaviour on Declude based systems. Andrew.
    ------------------------------------------------------------------------
    *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
    Behalf Of *Chris Patterson
    *Sent:* Monday, February 19, 2007 11:20 AM
    *To:* [email protected]
    *Subject:* RE: [Declude.JunkMail] Declude/Sniffer Issues

    When this issue happens which seems more frequent, I do clear out
    the thousands of left behind files.  I am more trying to find a
    way to prevent it or reason that is happening.

    And yes, Sniffer does have a hard time operating when it hoses up
    that bad.

    ------------------------------------------------------------------------

    *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
    Behalf Of *Darrell ([EMAIL PROTECTED])
    *Sent:* Monday, February 19, 2007 1:40 PM
    *To:* [email protected]
    *Subject:* Re: [Declude.JunkMail] Declude/Sniffer Issues

    Chris,

    I am gathering that you are running Sniffer in persistant mode?  I
    would stop your declude and Sniffer services.  Than go into the
    sniffer directory and remove all of the *.fin, *.svr files.  I am
    not sure what the .xxx files are.  I have yet to see those.  Than
    I would check your Sniffer log for any errors.  After making sure
    there are no errors I would restart the Sniffer persistant service
    and Declude and see if the issue is resolved.  It's possible
    Sniffer could be stepping on itself trying to weed through all
those files.
    Darrell

    ------------------------------------------------------------------------
    Check out http://www.invariantsystems.com for utilities for
    Declude And Imail.  IMail/Declude Overflow Queue Monitoring,
    SURBL/URI integration, MRTG Integration, and Log Parsers.

        ----- Original Message -----

        *From:* Chris Patterson <mailto:[EMAIL PROTECTED]>

        *To:* [email protected]
        <mailto:[email protected]>

        *Sent:* Monday, February 19, 2007 1:03 PM

        *Subject:* RE: [Declude.JunkMail] Declude/Sniffer Issues

        I get this in logs:

        02/19/2007 05:16:12.213 23859386 ERROR: External program
        SNIFFER didn't finish quick enough; terminating.

        02/19/2007 05:16:12.213 23859386 Couldn't get external program
        exit code

        At this point I see thousands of .xxx and .fin files built up
        in the sniffer directory.  Usually forcing a sniffer update
        (normally done every hour automatically).

        ------------------------------------------------------------------------

        *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
        Behalf Of *Darrell ([EMAIL PROTECTED])
        *Sent:* Monday, February 19, 2007 9:32 AM
        *To:* [email protected]
        *Subject:* Re: [Declude.JunkMail] Declude/Sniffer Issues

        What are you seeing the logs that indicates this?  Declude
        will terminate long running external processes and log that it
        terminated it.   Are you seeing those entries?  Also, during
        these times when you look at task manager do you see a bunch
        of idle sniffer processes?

        Typically from my experience when you see all the threads
        being used with very little to no CPU usage it tends to be a
        DNS issue (i.e slow or not responding DNS server).

        Darrell

        ------------------------------------------------------------------------
        Check out http://www.invariantsystems.com for utilities for
        Declude And Imail.  IMail/Declude Overflow Queue Monitoring,
        SURBL/URI integration, MRTG Integration, and Log Parsers.

            ----- Original Message -----

            *From:* Chris Patterson <mailto:[EMAIL PROTECTED]>

            *To:* [email protected]
            <mailto:[email protected]>

            *Sent:* Monday, February 19, 2007 8:47 AM

            *Subject:* [Declude.JunkMail] Declude/Sniffer Issues

            I am running 2 versions of Smartermail & Declude both
            running Sniffer and InvURIBL.  One is
            Smartermail4/Declude4.3.3 Other is Smartermail2/Declude3.

            These servers can run perfectly for weeks but for the past
            few weeks we have been sporadically seeing Declude back up
            files in the Proc directory.

            At this time all Declude threads are being used with no
            processing power being used.  It appears Sniffer is not
            finishing and hogging up all the threads after reviewing
            the logs.

            Anyone else experiencing this?

            Thanks,

            Chris Patterson, CCNA
            Network Engineer/Support Manager
            Rapid Systems


            ---
            This E-mail came from the Declude.JunkMail mailing list. To
            unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
            type "unsubscribe Declude.JunkMail". The archives can be found
            at http://www.mail-archive.com.


        ---
        This E-mail came from the Declude.JunkMail mailing list. To
        unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
        type "unsubscribe Declude.JunkMail". The archives can be found
        at http://www.mail-archive.com.
        ---
        This E-mail came from the Declude.JunkMail mailing list. To
        unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
        type "unsubscribe Declude.JunkMail". The archives can be found
        at http://www.mail-archive.com.


    ---
    This E-mail came from the Declude.JunkMail mailing list. To
    unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
    type "unsubscribe Declude.JunkMail". The archives can be found
    at http://www.mail-archive.com.
    ---
    This E-mail came from the Declude.JunkMail mailing list. To
    unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
    type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.

---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.


---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Reply via email to