Hi,

Hopefully someone can me work this out.

The mail comes from cron, showing the output of the job that has run. The
mail is delayed by one day. Here is the extract from the maillog:

Mar 26 19:00:05 server1 sendmail[14291]: m2PJ01bU014291: to=<user1>,
ctladdr=<user1> (1009/1012), delay=1+00:00:04, xdelay=00:00:01,
mailer=relay, pri=3739618, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0,
stat=Sent (m2QJ04t9008251 Message accepted for delivery)

All other cron mails seem to be delivered on time. The box is quite
heavily loaded, but this is true all the time so I dont think that is the
problem.

We are using Redhat AS 4 Update 4, with sendmail 8.13.1-3.

I would also like to know where the mail is being kept for these 24 hours,
as I can't seem to find it in /var/spool/mqueue or /var/spool/clientmqueue

Any Ideas?

Cheers

Ceri

Ceri Townsend <cerit@nospam.teleord.co.uk> wrote:
> Hopefully someone can me work this out.
>
> The mail comes from cron, showing the output of the job that has run. The
> mail is delayed by one day. Here is the extract from the maillog:
>
> Mar 26 19:00:05 server1 sendmail[14291]: m2PJ01bU014291: to=<user1>,
> ctladdr=<user1> (1009/1012), delay=1+00:00:04, xdelay=00:00:01,
> mailer=relay, pri=3739618, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0,
> stat=Sent (m2QJ04t9008251 Message accepted for delivery)
>
> All other cron mails seem to be delivered on time. The box is quite
> heavily loaded, but this is true all the time so I dont think that is the
> problem.
>
> We are using Redhat AS 4 Update 4, with sendmail 8.13.1-3.
>
> I would also like to know where the mail is being kept for these 24 hours,
> as I can't seem to find it in /var/spool/mqueue or /var/spool/clientmqueue
>
> Any Ideas?
>
> Cheers
>
> Ceri

1) Locate (and post) *OTHER* log entries created by the message.
grep m2PJ01bU014291 _the-log-file_
2) Scan the log for "overload" reports

--
[pl>en: Andrew] Andrzej Adam Filip : anfi@priv.onet.pl : anfi@xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Perhaps the remembrance of these things will prove a source of future
pleasure.
-- Virgil

Greg Russell <me@privacy.net> wrote in
news:652u8oF2digd3U2@mid.individual.net:

> Yes it does, and it reinforces my original suggestion: carefully
> analyze the nature of the cron job.
>
> Here for example is the relevant portion of the mail log entry from a
> cron job that starts at 23:42 every evening and takes almost 15
> minutes to complete (a leafnode update). Carefully notice the
> "delay=00:14:53" value, and add it to the cron start time of 23:42,
> then notice how the sum of the two times correlates to the 23:56:54
> syslogd timestamp:
>
> Mar 26 23:56:54 meister17 sendmail[3286]: m2R6g1It003286: to=root,
> ctladdr=root (0/0), delay=00:14:53, xdelay=00:00:04, mailer=relay,
> pri=32848, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent
> (m2R6uodp003301 Message accepted for delivery)
>
> I will suggest that your cron job appears to take 86400+ seconds to
> complete, which you can verify by prepending the cronjob with "time",
> which result will also be emailed to you, e.g.:
>
> 0 19 * * * time /path/to/your/job
>
> This why you won't see the mail in the queue during this time; the
> data haven't yet been submitted since the pipe was opened. You will
> however see the process existing during that entire time with "ps auxw
> | grep CronDaemon"
>

Hi,

When I looked at the ps output I do indeed see a line which appears to
be the offending article. What was confusing me was that as far as I
could tell the cron job had finished. Having examined the script, I
noticed that the last thing it does is start our application server, and
this is where the problem is coming from. The application server doesnt
get stopped until the cron job runs again the next day..which would
explain the delay.

So now I just need to get the script changed. The wierd thing is that
this script was working fine before we upgraded the server (from RH2.1
to RH4), so I guess something changed with the upgrade.

Thanks for everyones .

Cheers

Ceri