Unfortunately, I never found an answer but on the flip side, the problem seems to have gone away. For how long, I'm not sure but I've been watching carefully and maintaining good backups of /var/mail. I followed a number of suggestions but I did not find anything that would cause the files to disappear. I thank the following people and their suggestions: -- "Mike's List" <mikelist@sky.net> Try ps -ef | grep map (looking for imap processes) and determine any from wcbrown and try terminating it...if still doesn't work, try init 6 during maintenance hours (but since mail isn't working right now) or immediately and see if it'll help. Ask the user to download his mail instead of leaving it on the server... 70MB is huge, perhaps some sort of quota is reach and cause the problem? -- Gert-Jan Hagenaars <gj@hagenaars.com> You might want to install lsof to find out which process has the mailbox open. You might have to do some funky stuff (like tail your log file for the imapd message below, and use that as a trigger to send you the output of lsof). -- William Yodlowsky <wyodlows@andromeda.rutgers.edu> Is /var/mail an NFS mount? If so, network problems or NFS server problems might be at work... Do dmesg / syslog show anything about media errors on the disks? You might want to run ps and ls through the Sun fingerprint database (on Sunsolve) if you don't run tripwire, just to be sure nothing funny has happened to your binaries... -- Fabrice Guerini <fabrice@bluemartini.com> I don't know if this will apply to your particular problem, but do you happen to be mounting /var/mail from a "trans" type SDS partition? I have seen similar strange occurrences at another site before (although the mailboxes didn't all disappear), but was never able to track down the root cause. -- "Steve Moccio" <svm@lucent.com Is /var/mail mounted locally or is it an nfs mount from a mail server? If so is your nfs mount being killed? -- Ric Anderson <ric@Opus1.COM> The error you mention can be caused if multiple things go for the same mailbox. e.g., you decided to read your mail from a lab, while your mail client on your dorm machine still had the mailbox open. Its a fairly frequent happening on my IMAP server. Check the permissions on /var/mail. It should be 0775, group mail, user root, e.g. drwxrwxr-x 3 root mail 512 Mar 12 13:01 /var/mail or maybe mode 1777 drwxrwxrwt (like /tmp). If its mode 0777, then any logged in user can "rm /var/mail/*". If you have process accounting enabled, then lastcomm rm might shed some light on things, if you find an "rm" executed around the time mail vanished. -- pgm@mega.eu.turner.com Sorry I don't know the answer, do you think the news group comp.mail.imap might be worth a try? -- "Bara Zani" <bara_zani@yahoo.com> check to see if there's no automount to mount something on /var also see if there's no clean up scripts in /etc/init.d check cron entries for user root . -- "Jay Chembakassery" <jay@bluewireless.com> I dont think the file size is the culprit. I have mail boxes with with size more than 150MB !! Looks like a hack. Check the /var/mail/syslog for the IP addresess from which the requests came for 'wcbrown'. What`s the version of your IMAP ? Why can`t you implement the secure IMAP ? -- Jay Lessert <jayl@accelerant.net> Yow. It seems *very* unlikely that imapd did this, but you never know. Are permissions on /var/mail correct? % ls -ld /var/mail drwxrwxrwt 2 root 1536 Mar 14 09:28 /var/mail Check all crontab and at entries. Check all currently running processes. Even though you're sure you haven't been cracked, be paranoid. Check your ls and ps binaries against Sun md5 fingerprints: http://www.sun.com/blueprints/0501/Fingerprint.pdf http://sunsolve.Sun.COM/pub-cgi/fileFingerprints.pl If *still* nothing, then turn on auditing: http://www.securityfocus.com/focus/sun/articles/bsmaudit1.html http://www.sun.com/blueprints/0201/audit_config.pdf Also AnswerBook has a good non-manpage section. My old audit_control file back in a day when I had some minor problems to chase down (not as bad as yours, thank goodness) was: /etc/security/audit_control: # dir:/var/audit flags:+fw,+fd ...which logs *successful* ("+") file writes and file deletes. -- Chris <chris@geddings.org> Uwash Imap has a driver called "mbox" which generally copies a users mail to their $HOME/mbox when connecting via imap. Has any configuration (update, etc) changed that may have caused that? Does this folder ($HOME/mbox) exist for the affected users. I *believe* the default behavior for this driver is not to move the mail unless a file exists in their home directory called mbox. This is a compiled in option w/ uwash imap, and the only way to completely disable it is to recompile the imap server. Hope this helps, -- "Hugo Jose C C Dias" <hdias@tj.ba.gov.br> I would check how is the locking strategies used by the mailer program (procmail, mailx, etc..). As this software write at the same file the IMAP or POP, its need to compiled with the same lock system (lock at bellow). If you are using sendmail lock at Mlocal parameters at sendmail.cf to see what mailer are you using. procmail v3.21 2001/06/29 Copyright (c) 1990-1999, Stephen R. van den Berg <srb@cuci.nl> Copyright (c) 1997-2001, Philip A. Guenther <guenther@sendmail.com> Submit questions/answers to the procmail-related mailinglist by sending to: <procmail-users@procmail.org> And of course, subscription and information requests for this list to: <procmail-users-request@procmail.org> Locking strategies: dotlocking, lockf() Default rcfile: $HOME/.procmailrc It may be writable by your primary group Your system mailbox: /var/spool/mail/root ##################### Original message I have a Sun E450 filserver running Solaris7. All my users mailboxes are in /var/mail. Users read their mail mostly by IMAP connections and one logs in and uses Pine. Things have been working fine for two years until two days ago. Two days in a row at two different times, everyone's mailboxes disappeared from /var/mail. I'm the only administrator. I haven't changed anything on the server and don't see signs of foul play. The only clue I have about the time the mailbox files disappeared was the following message: Mar 12 13:41:20 csb imapd[1844]: Fatal mailbox error user=wcbrown host=valiant.mathsci.usna.edu mbx=/var/mail/wcbrown: Mailbox modified by another process. Cannot continue! Mar 13 15:45:54 csb imapd[1005]: Fatal mailbox error user=wcbrown host=valiant.mathsci.usna.edu mbx=/var/mail/wcbrown: Mailbox modified by another process. Cannot continue! What process could be causing this all of a sudden? The users' "wcbrown" mailbox is 70MB if that makes a difference. I'm theorizing the mailbox size or an IMAP configuration is the culprit. I did read some things about pine but I don't believe pine was being used in the first incident. All users mailboxes are rw------- and owned only by the mailbox owner... HELP! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn A. Mayr (UNIX System Administrator) Voice: (410) 293-6808 (sec-6800) Computer Science Department, DivMath&Sci Email: carolyn@usna.edu 572 Holloway Road, Chauvenet Hall, Stop 9F FAX: (410) 293-2686 U.S. Naval Academy WWW: http://www.cs.usna.edu Annapolis, MD 21402-5002 USNA: (410) 293-1000 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Mar 19 11:37:37 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:37 EST