Skip navigation
This discussion is archived

Mail: postfix/pipe : warning: pipe_command_write: write time limit ..

3943 Views 7 Replies Latest reply: Jun 26, 2009 8:07 AM by sensadrome RSS
flatrack Calculating status...
Currently Being Moderated
Mar 3, 2009 7:20 AM
Anyone run into the following situation:

1) "postfix/pipe : warning: pipecommandwrite: write time limit exceeded" error messages start showing up in system.log
2) The postfix queue starts filling up with mail to be delivered for a particular user. User reports that mail is not being delivered.
3) The user has a hung IMAPd process that refuses to die. kill -9 <pid> does not work for the process, and a hard reset of the server is needed (push the button since shutdown hangs due to the hung imapd process) to get things back in order. Also, a reconstruct of the users mailbox seems to smooth things out after the reboot.

The postfix/pipe message seems to indicate that postfix is unable to deliver the mail, which is why it's sitting in the queue. I'm guessing that the hung IMAPd process has locked out the users mailbox, or something of that nature.

Right now, I have a script that tails the system.log, grep's for these messages and sends me an email with the contents of the postfix queue. This helps alert me to the situation, but it would be nice to either fix it or get a better idea of what's going on.

The user usually affected by this is using Mail.app on 10.4.11.

Thanks in Advance,
Flatrack
Xserve Intel, Mac OS X (10.5.6)
  • pterobyte Level 6 Level 6 (10,910 points)
    If it always affects the same user, try and reconstruct at the command line (Server Admin does not help):
    sudo /usr/bin/cyrus/bin/reconstruct -r -f user/username

    Also check /var/log/mailaccess.log for clues while the user has issues (may need to up the logging level for IMAP)
    Mac OS X (10.5.6)
  • Fred Turner Level 1 Level 1 (80 points)
    YESSSSS!!! I am having this same problem on a server that I'm administering. Talk about incredibly frustrating. I'm seeing the exact same behavior:

    One user's IMAP process gets hung up and gradually takes down the entire service. No amount of Force Quitting or "kill"-ing will work...that process just keeps on staying hung up. And soft restarting is ineffective.

    In my case, it is the same user every time. I had it happen once in January (while I was out of town, of course), then not again until 3-4 times this past Thursday-Saturday (yep, the server knew I was out of town again). End user told me today that he'd had to force quit Mail several times recently...during the same timeframe as the hangups. I have done some major cleaning up, overhauling, and mailbfr-ing of this user's account, and will be watching it like a hawk for some time to come, but the main problem I see is:

    *SO WHAT* if a lone user's account gets corrupted?!?! Or if the end user jerks the rug out from under Mail by Force Quitting?!?! In NO WAY should that cause such a problem that the server won't even soft restart or allow that IMAP process to be killed. This is causing me a large Mac OS X Server credibility headache right now. My tech liaison and I have been gradually transitioning from PC + Exchange Server to Mac + Leopard Server, and having a single user's fouled up email account bring down the whole works is NOT acceptable.

    What can we do to further fix/debug/repair this? Of course the user account can be rebuilt, but this should not be taking the entire IMAP service down and then not allowing the server to restart or kill off the process.

    Fred
    Mac Pro 8x2.8GHz, 4GB, Mac OS X (10.5.6), Leopard Server 10.5.6
  • pterobyte Level 6 Level 6 (10,910 points)
    Did you restore just the single user or the whole IMAP database (mailbfr -m or -f)?
    There are circumstances were the db can be broken in a way that a single user reconstruction will not help or only help temporarily.

    Also, what errors do you see in mailaccess.log when this happens?

    Furthermore, make sure the user doesn't by accident exist twice (username in small caps and once in mixed caps for example).

    Alex
    Mac OS X (10.5.6)
  • Fred Turner Level 1 Level 1 (80 points)
    Thanks, Alex!

    I don't remember the exact instance where I did this, as I was out of town and pretty busy when the problem cropped up most recently, but on one of the times, I did rebuild the entire database w/ the "-f" option. Therefore, I'm not sure if the problem has occurred again after the full rebuild, but I believe it may have. I'm keeping a very close watch on it now, so if it occurs again, I'll hopefully be ready.

    I did not show any errors in mailaccess.log, but during the debacle, I have raised the logging level to Debug, so I can see everything now. I don't really want the problem to occur again, but it'd almost be nice to further narrow it down w/ logging, etc.

    This user does not exist twice, that I know of. Using the standard methods, I only see the user "frank". Should I be looking elsewhere? BTW, I also had to manually reconstruct the OD user info 2 nights ago in the aftermath of the latest hard restart. Instead of "franksmith", I changed the short name to "frank", then cp'ed the IMAP folder and changed the name. Seems to be working okay presently.

    Don't know if this will help, but here is the "ps" entry for the hung process:

    +2737 ?? 0:00.02 imapd: cs662599-213.bham.res.rr.com [66.25.99.213] franksmith us+

    Thanks,
    Fred
    Mac Pro 8x2.8GHz, 4GB, Mac OS X (10.5.6), Leopard Server 10.5.6
  • pterobyte Level 6 Level 6 (10,910 points)
    Fred,

    Therefore, I'm not sure if the problem has occurred again after the full rebuild, but I believe it may have. I'm keeping a very close watch on it now, so if it occurs again, I'll hopefully be ready.


    So we have to wait to see if it is cured or not

    This user does not exist twice, that I know of. Using the standard methods, I only see the user "frank". Should I be looking elsewhere?


    Assuming you use default locations, open terminal and issue:
    sudo ls -l /var/spool/imap/user

    It will show you a list of all mailboxes on your server.

    Alex
    Mac OS X (10.5.6)
  • Fred Turner Level 1 Level 1 (80 points)
    Hey Alex & Flatrack--

    Well, thus far no further troubles w/ the user "frank's" IMAP account, but I'm still waiting for another hiccup. Hopefully it won't happen again, and maybe the rebuild did the trick. Not much else to report, but if I notice any trouble, I'll be scouring the logs, which are now set to "Debug" level.

    Would still like to know your thoughts on the whole problem w/ the hung imapd process bringing the entire server down and requiring a dirty restart. Seems to me like no matter what happens w/ a user's IMAP account, the rest of the server should not be affected or need restarting. Any thoughts?
    PowerBook G4/1.67GHz, Mac OS X (10.5.6)
  • sensadrome Level 1 Level 1 (0 points)
    Hi there,

    I too am seeing this problem. A process is holding open the cyrus files (header, index, cache) in the user's folder (lsof | grep cyrus | grep <username>) and this process cannot be killed, nor it's parent. I can't even delete the offending files as root (I was planning to then reconstruct that mailbox).

    The only solution was a hard reboot - having to pull the power out too which does seem enormously excessive (even Windows-like !)

    At present I can't even tell what is causing the issue - the client is Apple Mail in an office of just 15 people (with an admittedly excessive amount of email - most are lawyers). My thoughts were to check the disk drives for errors, but I am no longer convinced this is the issue.

    Posting here in the hope that someone has got further with this ?

    Simon
    Macbook Pro, Mac OS X (10.5.7)

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.