Why isn't qmgr picking up emails from the maildrop directory?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Why isn't qmgr picking up emails from the maildrop directory?

Ward, Martin
Why isn't qmgr picking up emails from the maildrop directory?

I had a number of emails that were stuck in my incoming directory after I had stopped the server for some preventative maintenance., so after I restarted Postfix I ran "postsuper -r ALL" to requeue them. They moved to the maildrop directory (which I understand to be correct) but they are not being picked up. Can someone please offer some suggestions for areas to look?

Before someone mentions it, yes, the postfix daemons are running!

# ps -ef|grep postf
 postfix 27613 14698   0 10:32:42 ?           0:00 qmgr -l -t fifo -u
    root 14698     1   0   Jun 05 ?           1:36 /opt/postfix/libexec/master
 postfix 22016 14698   0 10:02:01 ?           0:00 pickup -l -t fifo -u
 postfix 22017 14698   0 10:02:01 ?           0:00 cleanup -z -t unix -u
    root 29523 28204   0 10:43:11 pts/1       0:00 grep postf

|\/|artin
--
Martin Ward
Network Systems Operations Specialist
DDI:    +44 (0) 20 7863 5218
Fax:    +44 (0) 20 7863 5610
Mob:    +44 (0) 7971 97 77 21
www.colt.net

Data | Voice | Managed Services

Help reduce your carbon footprint | Think before you print

COLT Telecommunications, Beaufort House, 15 St Botolph Street, London, EC3A 7QN UK
Registered in England and Wales, registered number 02452736, VAT number GB 645 4205 50



*************************************************************************************
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.

The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing [hidden email] and delete the message and any attachments without retaining any copies.

Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.

No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.

Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.
Reply | Threaded
Open this post in threaded view
|

Re: Why isn't qmgr picking up emails from the maildrop directory?

Wietse Venema
Ward, Martin:
> I had a number of emails that were stuck in my incoming directory after
> I had stopped the server for some preventative maintenance., so after I
> restarted Postfix I ran "postsuper -r ALL" to requeue them. They moved
> to the maildrop directory (which I understand to be correct) but they
> are not being picked up. Can someone please offer some suggestions for
> areas to look?

Mail is picked up by the (surprise) pickup daemon. It scans the
maildrop queue every 60 seconds (as configured in master.cf) or
when triggered by local mail submission.

If you're running MacOS X, then this is different. You did not
say what operating system you are using.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: Why isn't qmgr picking up emails from the maildrop directory?

Ward, Martin
In reply to this post by Ward, Martin

Wietse Venema wrote:

> Ward, Martin:
> > I had a number of emails that were stuck in my incoming directory
> > after I had stopped the server for some preventative
> maintenance., so
> > after I restarted Postfix I ran "postsuper -r ALL" to requeue them.
> > They moved to the maildrop directory (which I understand to be
> > correct) but they are not being picked up. Can someone please offer
> > some suggestions for areas to look?
>
> Mail is picked up by the (surprise) pickup daemon. It scans
> the maildrop queue every 60 seconds (as configured in
> master.cf) or when triggered by local mail submission.
>
> If you're running MacOS X, then this is different. You did
> not say what operating system you are using.

Sorry, I should have stated I am running Postfix on Solaris 10.

The pickup daemon is certainly running and is enabled in the master.cf
file: ==== # ps -ef|grep -i pick
 postfix 27553  2117   0 10:55:29 ?           0:00 pickup -l -t fifo -u
    root  7176 26727   0 11:48:31 pts/1       0:00 grep -i pick
# grep pickup /etc/postfix/master.cf
pickup    fifo  n       -       n       60      1       pickup
#
====

Although a quick look at the files and directories this daemon has open
doesn't show it looking in the maildrop directory this may simply be
because it's already opened and closed it: ==== # pfiles /proc/27553
27553:  pickup -l -t fifo -u
  Current rlimit: 2048 file descriptors
   0: S_IFCHR mode:0666 dev:270,0 ino:6815752 uid:0 gid:3 rdev:13,2
      O_RDWR
      /devices/pseudo/mm@0:null
   1: S_IFCHR mode:0666 dev:270,0 ino:6815752 uid:0 gid:3 rdev:13,2
      O_RDWR
      /devices/pseudo/mm@0:null
   2: S_IFCHR mode:0666 dev:270,0 ino:6815752 uid:0 gid:3 rdev:13,2
      O_RDWR
      /devices/pseudo/mm@0:null
   3: S_IFIFO mode:0000 dev:278,0 ino:19779535 uid:0 gid:0 size:100
      O_RDWR|O_NONBLOCK FD_CLOEXEC
   4: S_IFIFO mode:0000 dev:278,0 ino:19779535 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
   5: S_IFSOCK mode:0666 dev:276,0 ino:59450 uid:0 gid:0 size:0
      O_RDWR FD_CLOEXEC
        SOCK_STREAM
        SO_SNDBUF(16384),SO_RCVBUF(5120)
        sockname: AF_UNIX
   6: S_IFIFO mode:0622 dev:32,323 ino:15076 uid:212 gid:10015 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
      /var/spool/postfix/public/pickup
   7: S_IFCHR mode:0000 dev:270,0 ino:52995 uid:0 gid:0 rdev:21,259026
      O_WRONLY FD_CLOEXEC
      /devices/pseudo/log@0:conslog
   8: S_IFDOOR mode:0444 dev:279,0 ino:53 uid:0 gid:0 size:0
      O_RDONLY FD_CLOEXEC  door to ldap_cachemgr[242]
      /var/run/ldap_cache_door
#
====

Also, here is my postconf -n output:
====
# postconf -n
alias_maps = ldap:/etc/postfix/ldap-aliases.cf
bounce_queue_lifetime = 1d
command_directory = /opt/postfix/bin
config_directory = /etc/postfix
daemon_directory = /opt/postfix/libexec
debug_peer_level = 2
html_directory = /opt/postfix/htmldoc
in_flow_delay = 2
mail_owner = postfix
mailq_path = /opt/postfix/bin
manpage_directory = /opt/postfix/man
maximal_queue_lifetime = 7d
message_size_limit = 44040192
myhostname = smtp.example.com
mynetworks = cidr:/$config_directory/mynetworks
newaliases_path = /opt/postfix/bin/newaliases
proxy_interfaces = 192.168.0.2
queue_directory = /var/spool/postfix
readme_directory = /opt/postfix/doc
relay_domains = ldap:/etc/postfix/ldap/mxhosts.cf
sample_directory = /etc/postfix
sendmail_path = /opt/postfix/sbin/sendmail
setgid_group = postdrop
smtp_connect_timeout = 20s
smtp_helo_timeout = 60s
smtpd_client_connection_count_limit = 5
smtpd_client_event_limit_exceptions =
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_recipient_domain,
reject_unauth_pipelining, permit_mynetworks, reject_unauth_destination,
reject_non_fqdn_hostname, reject_invalid_hostname
unknown_local_recipient_reject_code = 550
====

|\/|artin


*************************************************************************************
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.

The contents of this message and its attachments are confidential and may also be subject to legal privilege.  If you are not the named addressee and/or have received this message in error, please advise us by e-mailing [hidden email] and delete the message and any attachments without retaining any copies.

Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.

No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.  

Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

Reply | Threaded
Open this post in threaded view
|

Re: Why isn't qmgr picking up emails from the maildrop directory?

Wietse Venema
Ward, Martin:

>
> Wietse Venema wrote:
> > Ward, Martin:
> > > I had a number of emails that were stuck in my incoming directory
> > > after I had stopped the server for some preventative
> > maintenance., so
> > > after I restarted Postfix I ran "postsuper -r ALL" to requeue them.
> > > They moved to the maildrop directory (which I understand to be
> > > correct) but they are not being picked up. Can someone please offer
> > > some suggestions for areas to look?
> >
> > Mail is picked up by the (surprise) pickup daemon. It scans
> > the maildrop queue every 60 seconds (as configured in
> > master.cf) or when triggered by local mail submission.
> >
> > If you're running MacOS X, then this is different. You did
> > not say what operating system you are using.
>
> Sorry, I should have stated I am running Postfix on Solaris 10.

The pickup daemon will open files in the maildrop directory that
have the proper file permissions and names. So, this would be
a good time to show an "ls -l" of the maildrop directory. Just
a couple files will do.

It is very well possible that you're looking at really old files
from aborted mail submissions, and that weren't cleaned up because
the mail submitting process was terminated with force.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: Why isn't qmgr picking up emails from the maildrop directory?

Ward, Martin
In reply to this post by Ward, Martin
Wietse Venema wrote:
>
> The pickup daemon will open files in the maildrop directory
> that have the proper file permissions and names. So, this would be
> a good time to show an "ls -l" of the maildrop directory.
> Just a couple files will do.
>
> It is very well possible that you're looking at really old
> files from aborted mail submissions, and that weren't cleaned
> up because the mail submitting process was terminated with force.

That looks feasible:
====
# ls -alt /var/spool/postfix/maildrop/ | head
total 4738098
drwx-wx---   2 postfix  postdrop 9977856 Jun 17 12:27 .
drwxr-xr-x  17 postfix  root         512 Jun 17 12:00 ..
-rwx------   1 postfix  postfix     7207 Jun 16 10:53 5F9BC32F0
-rwx------   1 postfix  postfix     2870 Jun  5 12:31 9412B97C96
-rwx------   1 postfix  postfix     1081 Jun  5 12:14 2E5CF97CE6
-rwx------   1 postfix  postfix     2940 Jun  5 11:56 1C8AA97CE5
-rwx------   1 postfix  postfix     3002 Jun  5 11:39 81EA597CDB
-rwx------   1 postfix  postfix     3209 Jun  5 11:22 BF6E397CEA
-rwx------   1 postfix  postfix     2282 Jun  5 11:04 8442B97AE6
====

These are the youngest of the files. Apart from the one file created 90
minutes ago everything else is more than twelve days old.

Does the pickup process have a maximum file age it will look at i.e. it
won't even open files more than 5 days old, or is it that it keeps
trying to open the files but if/as they are broken it keeps failing?

|\/|artin


*************************************************************************************
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.

The contents of this message and its attachments are confidential and may also be subject to legal privilege.  If you are not the named addressee and/or have received this message in error, please advise us by e-mailing [hidden email] and delete the message and any attachments without retaining any copies.

Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.

No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.  

Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

Reply | Threaded
Open this post in threaded view
|

Re: Why isn't qmgr picking up emails from the maildrop directory?

Wietse Venema
Ward, Martin:

> Wietse Venema wrote:
> >
> > The pickup daemon will open files in the maildrop directory
> > that have the proper file permissions and names. So, this would be
> > a good time to show an "ls -l" of the maildrop directory.
> > Just a couple files will do.
> >
> > It is very well possible that you're looking at really old
> > files from aborted mail submissions, and that weren't cleaned
> > up because the mail submitting process was terminated with force.
>
> That looks feasible:
> ====
> # ls -alt /var/spool/postfix/maildrop/ | head
> total 4738098
> drwx-wx---   2 postfix  postdrop 9977856 Jun 17 12:27 .

What is this postdrop directory doing here?

> drwxr-xr-x  17 postfix  root         512 Jun 17 12:00 ..
> -rwx------   1 postfix  postfix     7207 Jun 16 10:53 5F9BC32F0
> -rwx------   1 postfix  postfix     2870 Jun  5 12:31 9412B97C96
> -rwx------   1 postfix  postfix     1081 Jun  5 12:14 2E5CF97CE6
> -rwx------   1 postfix  postfix     2940 Jun  5 11:56 1C8AA97CE5
> -rwx------   1 postfix  postfix     3002 Jun  5 11:39 81EA597CDB
> -rwx------   1 postfix  postfix     3209 Jun  5 11:22 BF6E397CEA
> -rwx------   1 postfix  postfix     2282 Jun  5 11:04 8442B97AE6
> ====
>
> These are the youngest of the files. Apart from the one file created 90
> minutes ago everything else is more than twelve days old.

The youngest file is from June 16, if I am not mistaken.

Before I forget, two questions:

1) Does Postfix deliver mail that you post with the Postfix sendmail
command? If not, then "postsuper -r ALL" is a complete red herring
and you have a different problem.

2) Are there any pickup messages in the maillog file that aren't
related to normal mail delivery?

If none of this turns on the light bulb, it may be instructive to
watch the verbose pickup logging as it traverses the maildrop
directory. Append *one* -v option to the pickup line in master.cf
and do "postfix reload". Unfortunately it will not log all the
reasons why a file file is being skipped, because it has to skip
incomplete mail during normal routine activity.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Why isn't qmgr picking up emails from the maildrop directory?

Victor Duchovni
On Tue, Jun 17, 2008 at 09:19:37AM -0400, Wietse Venema wrote:

> Ward, Martin:
> > Wietse Venema wrote:
> > >
> > > The pickup daemon will open files in the maildrop directory
> > > that have the proper file permissions and names. So, this would be
> > > a good time to show an "ls -l" of the maildrop directory.
> > > Just a couple files will do.
> > >
> > > It is very well possible that you're looking at really old
> > > files from aborted mail submissions, and that weren't cleaned
> > > up because the mail submitting process was terminated with force.
> >
> > That looks feasible:
> > ====
> > # ls -alt /var/spool/postfix/maildrop/ | head
> > total 4738098
> > drwx-wx---   2 postfix  postdrop 9977856 Jun 17 12:27 .
>
> What is this postdrop directory doing here?


Looks OK to me. What is wrong is that /var/spool/postfix (".." below)
belongs to Postfix and not "root", I don't think that explains the issues,
but it still worth correcting.

> > drwxr-xr-x  17 postfix  root         512 Jun 17 12:00 ..

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

RE: Why isn't qmgr picking up emails from the maildrop directory?

Ward, Martin
In reply to this post by Ward, Martin
Wietse Venema wrote:
> The youngest file is from June 16, if I am not mistaken.

I've been doing that all day today, "Date blindness" I think it's
called. You are right, the youngest email is just over a day old, the
rest date back to 5th June, twelve days ago.

> Before I forget, two questions:
>
> 1) Does Postfix deliver mail that you post with the Postfix
> sendmail command? If not, then "postsuper -r ALL" is a
> complete red herring and you have a different problem.

Hmm, no, it doesn't seem to work. I sent an email using sendmail about
ten minutes ago and it's still in the maildrop directory.

> 2) Are there any pickup messages in the maillog file that
> aren't related to normal mail delivery?

TBH I am not sure what a 'normal' pickup message looks like. For each
email there seems to be two entries, neither of which looks anything
like the standard email routing I am used to seeing:

Jun 17 14:30:36 mc23.lon.dcn.colt.net postfix/pickup[21238]: [ID 947731
mail.warning] warning: E2792392B: message has been queued for 12 days
Jun 17 14:30:36 mc23.lon.dcn.colt.net postfix/pickup[21238]: [ID 197553
mail.info] E2792392B: uid=212 from=<[hidden email]>
orig_id=1EB522F6C2

Also I can't find any mention of the test email I sent using Postfix's
sendmail. I grep'ed for the mail code of the email (i.e. the name of the
file in the maildrop directory) but found nothing.


> If none of this turns on the light bulb, it may be
> instructive to watch the verbose pickup logging as it
> traverses the maildrop directory. Append *one* -v option to
> the pickup line in master.cf and do "postfix reload".
> Unfortunately it will not log all the reasons why a file file
> is being skipped, because it has to skip incomplete mail
> during normal routine activity.

I tried this (just to be thorough) but it didn't return any more
information than I detailed above.

So, as you stated, it looks like I have a different problem. I changed
the /var/spool/postfix directory owner as Viktor suggested so the
maildrop ownership looks like this:

# ls -al /var/spool/postfix/maildrop/ | head
total 4734092
drwx-wx---   2 postfix  postdrop 9977856 Jun 17 14:55 .
drwxr-xr-x  17 root     root         512 Jun 17 14:00 ..
-rwx------   1 postfix  postfix     3082 Jun  5 06:10 000038A92D
-rwx------   1 postfix  postfix     3130 Jun  4 13:46 000063313E
-rwx------   1 postfix  postfix     1268 Jun  3 13:42 00008396A1
-rwx------   1 postfix  postfix     1311 Jun  5 03:14 0000982186
-rwx------   1 postfix  postfix     4914 Jun  4 11:32 0000E69209
-rwx------   1 postfix  postfix     4956 Jun  4 16:42 000156E6E5

So that looks OK. Every other directory under /var/spool/postfix is
owned by the postfix although the permissions are different in places:

# ls -al /var/spool/postfix/
total 97842
drwxr-xr-x  17 root     root         512 Jun 17 14:00 .
drwxr-xr-x   8 root     bin          512 Jan 23  2007 ..
drwx------   2 postfix  root      410112 Jun 17 14:55 active
drwx------   2 postfix  root      278016 Jun 17 14:55 bounce
drwx------   2 postfix  root         512 Nov  7  2007 corrupt
drwx------  18 postfix  root         512 Feb 13 09:28 defer
drwx------  18 postfix  root         512 Feb  1  2007 deferred
drwx------   2 postfix  root       59904 Jun  5 08:46 flush
drwx------   2 postfix  root         512 Jan 22  2007 hold
drwx------   2 postfix  root     9990656 Jun 17 14:55 incoming
drwx-wx---   2 postfix  postdrop 9977856 Jun 17 14:55 maildrop
drwxr-xr-x   2 root     root         512 Feb 13  2007 pid
drwx------   2 postfix  root         512 Mar 31 12:26 private
drwx--x---   2 postfix  postdrop     512 Mar 31 12:26 public
drwx------   2 postfix  root         512 Jan 22  2007 saved
drwx------   2 postfix  root         512 May 31 20:59 trace

This doesn't look to be a problem from what info I can find though.

|\/|artin


*************************************************************************************
The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way.

The contents of this message and its attachments are confidential and may also be subject to legal privilege.  If you are not the named addressee and/or have received this message in error, please advise us by e-mailing [hidden email] and delete the message and any attachments without retaining any copies.

Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses.

No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party.  

Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

Reply | Threaded
Open this post in threaded view
|

Re: Why isn't qmgr picking up emails from the maildrop directory?

Wietse Venema
Ward, Martin:
> > Before I forget, two questions:
> >
> > 1) Does Postfix deliver mail that you post with the Postfix
> > sendmail command? If not, then "postsuper -r ALL" is a
> > complete red herring and you have a different problem.
>
> Hmm, no, it doesn't seem to work. I sent an email using sendmail about
> ten minutes ago and it's still in the maildrop directory.
...
> Jun 17 14:30:36 mc23.lon.dcn.colt.net postfix/pickup[21238]: [ID 947731
> Jun 17 14:30:36 mc23.lon.dcn.colt.net postfix/pickup[21238]: [ID 197553

So it is pickup up mail. It may take a while before it finds
the one that you submitted moments ago.

> > If none of this turns on the light bulb, it may be
> > instructive to watch the verbose pickup logging as it
> > traverses the maildrop directory. Append *one* -v option to
> > the pickup line in master.cf and do "postfix reload".

The "postfix reload" will take effect when the pickup server
completes the queue scan that is currently in progress. Considering
that your maildrop is 9MB large, that means it will take a while.

> # ls -al /var/spool/postfix/
> total 97842
> drwxr-xr-x  17 root     root         512 Jun 17 14:00 .
> drwxr-xr-x   8 root     bin          512 Jan 23  2007 ..
> drwx------   2 postfix  root      410112 Jun 17 14:55 active
...
> drwx-wx---   2 postfix  postdrop 9977856 Jun 17 14:55 maildrop

Some patience may be needed.

        Wietse