Orphaned "d" files in sendmail queue
Orphaned "d" files in sendmail queue
am 17.01.2008 22:57:37 von phillip.corchary
Can anyone help me understand how 'd' (data) files can become orphaned
in my sendmail queue?
Config is multiple sendmail boxes behind hardware vip. This acts as
relay for applications sending emails to known/registered customers,
so bad address volume is low. Sendmail servers run single queue.
Normally one will see this sort of thing:
# mailq | grep Total
Total requests: 105
# ls /var/spool/mqueue/ | grep -c ^d
105
# ls /var/spool/mqueue/ | grep -c ^q
105
But occasionally I will find that there are a significant number of
orphaned 'd' files, so I'll see something like this:
# mailq | grep Total
Total requests: 200
# ls /var/spool/mqueue/ | grep -c ^d
12406
# ls /var/spool/mqueue/ | grep -c ^q
200
Further investigation will show that the 'd' files with no
corresponding 'q' files are older than the sendmail retry timeout of
36 hours (sometimes they are a few weeks old even). Sometimes there is
a 'Q' file for the same message (what are these?), but most often
there only the 'd' file.
many of them will have a log such as this:
Jan 10 12:09:52 mail sendmail[18710]: m0AK9m5w018688: m0AK9q5v018710:
postmaster notify: Host unknown (Name server: somedomain.com: host not
found)
Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: to=root,
delay=00:00:01, xdelay=00:00:01, mailer=local, pri=35234, dsn=5.0.0,
stat=Can't create output
Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: m0AK9q5w018710:
return to sender: Can't create output
Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: Losing ./
qfm0AK9q5v018710: savemail panic
Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: SYSERR(root):
savemail: cannot save rejected email anywhere
Can anyone help me understand how this is happening?
Re: Orphaned "d" files in sendmail queue
am 21.01.2008 16:12:16 von Greg
Phil wrote:
> Can anyone help me understand how 'd' (data) files can become orphaned
> in my sendmail queue?
not much help, rather a "me too". I've also noticed this problem and it
doesnt always correspond to a broken SMTP connection. Sometimes it seems
to just fail to clean up properly.
Every 6 months or so I have a script which cleans up all the orphaned df
files. My experience of this is on 3 busy sendmail gateways on CentOS
4.6 It doesnt happen often enough for it to be a real problem, just a
loose end that I'd like tidied up.
GREG
Re: Orphaned "d" files in sendmail queue
am 23.01.2008 17:57:12 von phillip.corchary
So ... does anyone have any experience with this problem to offer some
suggestions?
On Jan 17, 2:57=A0pm, Phil wrote:
> Can anyone help me understand how 'd' (data) files can become orphaned
> in my sendmail queue?
>
> Config is multiple sendmail boxes behind hardware vip. This acts as
> relay for applications sending emails to known/registered customers,
> so bad address volume is low. Sendmail servers run single queue.
> Normally one will see this sort of thing:
>
> # mailq | grep Total
> =A0 Total requests: 105
> # ls /var/spool/mqueue/ | grep -c ^d
> =A0 105
> # ls /var/spool/mqueue/ | grep -c ^q
> =A0 105
>
> But occasionally I will find that there are a significant number of
> orphaned 'd' files, so I'll see something like this:
>
> # mailq | grep Total
> =A0 Total requests: 200
> # ls /var/spool/mqueue/ | grep -c ^d
> =A0 12406
> # ls /var/spool/mqueue/ | grep -c ^q
> =A0 200
>
> Further investigation will show that the 'd' files with no
> corresponding 'q' files are older than the sendmail retry timeout of
> 36 hours (sometimes they are a few weeks old even). Sometimes there is
> a 'Q' file for the same message (what are these?), but most often
> there only the 'd' file.
>
> many of them will have a log such as this:
>
> Jan 10 12:09:52 mail sendmail[18710]: m0AK9m5w018688: m0AK9q5v018710:
> postmaster notify: Host unknown (Name server: somedomain.com: host not
> found)
> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: to=3Droot,
> delay=3D00:00:01, xdelay=3D00:00:01, mailer=3Dlocal, pri=3D35234, dsn=3D5.=
0.0,
> stat=3DCan't create output
> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: m0AK9q5w018710:
> return to sender: Can't create output
> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: Losing ./
> qfm0AK9q5v018710: savemail panic
> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: SYSERR(root):
> savemail: cannot save rejected email anywhere
>
> Can anyone help me understand how this is happening?
Re: Orphaned "d" files in sendmail queue
am 23.01.2008 19:20:01 von schulz
In article <6cd99cb8-ae82-4944-ad19-7431f1aebe1e@s8g2000prg.googlegroups.com>,
Phil wrote:
>So ... does anyone have any experience with this problem to offer some
>suggestions?
If I recall correctly, there was a version of sendmail that had a bug that
would cause this problem. It was just a failure to clean up correctly, so
you could just delete those files every so often. The bug was fixed a year
or two ago. What version of sendmail do you have? The latest is 8.14.2.
>On Jan 17, 2:57=A0pm, Phil wrote:
>> Can anyone help me understand how 'd' (data) files can become orphaned
>> in my sendmail queue?
>>
>> Config is multiple sendmail boxes behind hardware vip. This acts as
>> relay for applications sending emails to known/registered customers,
>> so bad address volume is low. Sendmail servers run single queue.
>> Normally one will see this sort of thing:
>>
>> # mailq | grep Total
>> =A0 Total requests: 105
>> # ls /var/spool/mqueue/ | grep -c ^d
>> =A0 105
>> # ls /var/spool/mqueue/ | grep -c ^q
>> =A0 105
>>
>> But occasionally I will find that there are a significant number of
>> orphaned 'd' files, so I'll see something like this:
>>
>> # mailq | grep Total
>> =A0 Total requests: 200
>> # ls /var/spool/mqueue/ | grep -c ^d
>> =A0 12406
>> # ls /var/spool/mqueue/ | grep -c ^q
>> =A0 200
>>
>> Further investigation will show that the 'd' files with no
>> corresponding 'q' files are older than the sendmail retry timeout of
>> 36 hours (sometimes they are a few weeks old even). Sometimes there is
>> a 'Q' file for the same message (what are these?), but most often
>> there only the 'd' file.
>>
>> many of them will have a log such as this:
>>
>> Jan 10 12:09:52 mail sendmail[18710]: m0AK9m5w018688: m0AK9q5v018710:
>> postmaster notify: Host unknown (Name server: somedomain.com: host not
>> found)
>> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: to=3Droot,
>> delay=3D00:00:01, xdelay=3D00:00:01, mailer=3Dlocal, pri=3D35234, dsn=3D5.=
>0.0,
>> stat=3DCan't create output
>> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: m0AK9q5w018710:
>> return to sender: Can't create output
>> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: Losing ./
>> qfm0AK9q5v018710: savemail panic
>> Jan 10 12:09:53 mail sendmail[18710]: m0AK9q5v018710: SYSERR(root):
>> savemail: cannot save rejected email anywhere
>>
>> Can anyone help me understand how this is happening?
>
--
Tom Schulz
schulz@adi.com
Re: Orphaned "d" files in sendmail queue
am 24.01.2008 11:07:29 von Greg
Thomas Schulz wrote:
> In article <6cd99cb8-ae82-4944-ad19-7431f1aebe1e@s8g2000prg.googlegroups.com>,
> Phil wrote:
>> So ... does anyone have any experience with this problem to offer some
>> suggestions?
>
> If I recall correctly, there was a version of sendmail that had a bug that
> would cause this problem. It was just a failure to clean up correctly, so
> you could just delete those files every so often. The bug was fixed a year
> or two ago. What version of sendmail do you have? The latest is 8.14.2.
>
in my case, it is the stock sendmail in RHEL/CentOS 4.6 which identifies
itself as 8.13.1. The rpm is sendmail-8.13.1-3.2.el4. The patches
applied by redhat are listed in the specfile as:
Patch3: sendmail-8.12.2-makemapman.patch
Patch4: sendmail-8.12.11-smrsh-paths.patch
Patch5: sendmail-8.12.2-movefiles.patch
Patch7: sendmail-8.13.0-pid.patch
Patch9: sendmail-8.12.7-hesiod.patch
Patch10: sendmail-8.12.7-manpage.patch
Patch11: sendmail-8.13.0-dynamic.patch
Patch12: sendmail-8.13.0-cyrus.patch
Patch13: sendmail-8.13.1-errata_cataddr.patch
Patch14: sendmail-8.13.1-VU#834865.patch
Patch15: sendmail-8.13.1-VU#146718.patch
Patch16: sendmail-8.13.1-close_wait.patch
Patch17: sendmail-8.13.1-aliasespath.patch
Patch18: sendmail-8.13.1-localdomain.patch
now that I look at it, half of these appear to be "forward ported" from
the 8.12 branch and only two look like vulnerability fixes... I was
expecting more backported patches but perhaps I'm misinterpreting what I
see.
GREG
Re: Orphaned "d" files in sendmail queue
am 29.01.2008 17:59:59 von phillip.corchary
On Jan 24, 3:07 am, greg wrote:
> Thomas Schulz wrote:
> > In article <6cd99cb8-ae82-4944-ad19-7431f1aeb...@s8g2000prg.googlegroups.com>,
> > Phil wrote:
> >> So ... does anyone have any experience with this problem to offer some
> >> suggestions?
>
> > If I recall correctly, there was a version of sendmail that had a bug that
> > would cause this problem. It was just a failure to clean up correctly, so
> > you could just delete those files every so often. The bug was fixed a year
> > or two ago. What version of sendmail do you have? The latest is 8.14.2.
>
> in my case, it is the stock sendmail in RHEL/CentOS 4.6 which identifies
> itself as 8.13.1. The rpm is sendmail-8.13.1-3.2.el4. The patches
> applied by redhat are listed in the specfile as:
>
> Patch3: sendmail-8.12.2-makemapman.patch
> Patch4: sendmail-8.12.11-smrsh-paths.patch
> Patch5: sendmail-8.12.2-movefiles.patch
> Patch7: sendmail-8.13.0-pid.patch
> Patch9: sendmail-8.12.7-hesiod.patch
> Patch10: sendmail-8.12.7-manpage.patch
> Patch11: sendmail-8.13.0-dynamic.patch
> Patch12: sendmail-8.13.0-cyrus.patch
> Patch13: sendmail-8.13.1-errata_cataddr.patch
> Patch14: sendmail-8.13.1-VU#834865.patch
> Patch15: sendmail-8.13.1-VU#146718.patch
> Patch16: sendmail-8.13.1-close_wait.patch
> Patch17: sendmail-8.13.1-aliasespath.patch
> Patch18: sendmail-8.13.1-localdomain.patch
>
> now that I look at it, half of these appear to be "forward ported" from
> the 8.12 branch and only two look like vulnerability fixes... I was
> expecting more backported patches but perhaps I'm misinterpreting what I
> see.
>
> GREG
I have version 8.12.11, and it will NOT be easy to change. Anyone know
the bug # so I can dig out if my version is affected?
Thanks for the pointer....