topic Re: <usrname>.lock file in /var/mail is not being removed in Operating System - HP-UX

.lock file in /var/mail is not being removed

Chuck Sims — Thu, 10 Jun 2004 10:13:10 GMT

I have a user (paradigm) on one of my servers (barney) that can't receive mail. Mail to this user gets bounced back to the postmaster (root) with the following information:

----- The following addresses had permanent fatal errors -----

----- Transcript of session follows -----
/var/mail/paradigm.lock: File exists
mail: /var/mail/paradigm.lock not creatable after 100 tries
550 ... Can't create output

I've deleted the paradigm.lock file in /var/mail, but it just comes back the next time email is received for that user. I've also sent mail to myself on barney (the server), and that works well.

The problem appears to be that the .lock file is not being removed, but I don't know how to fix the problem. Any suggestions would be greatly appreciated.

Thanks...

- Chuck

Re: .lock file in /var/mail is not being removed

Ken Penland_1 — Thu, 10 Jun 2004 10:18:16 GMT

sounds like a permission problem...what is the permissions of the files/dirs?

Re: .lock file in /var/mail is not being removed

Mel Burslan — Thu, 10 Jun 2004 10:20:27 GMT

is your /var/mail permissions and ownership 775 [ bin:mail ] ?

Re: .lock file in /var/mail is not being removed

Ken Penland_1 — Thu, 10 Jun 2004 10:20:37 GMT

I found this thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=138668

it may help

Re: .lock file in /var/mail is not being removed

Jose Mosquera — Thu, 10 Jun 2004 10:25:01 GMT

Hi,

Pls cerify that "SENDMAIL_SERVER=1" into /etc/rc.config.d/mailservs file.
Then execute:
#/sbin/init.d/sendmail stop
#/sbin/init.d/sendmail start

This procedure guarantees the availabilty of your server to receive incoming messages

Pls try it.

Rgds.

Re: .lock file in /var/mail is not being removed

Uday_S_Ankolekar — Thu, 10 Jun 2004 10:26:54 GMT

Permission for mail directory could be an issue here: /var/mail should have permission like this
drwxrwxr-x 2 bin mail 1024 Jan 27 16:07 mail

and user should have
-rw-rw---- 1 paradigm mail

Re: .lock file in /var/mail is not being removed

Chuck Sims — Thu, 10 Jun 2004 11:24:26 GMT

Aloha All,

I don't think permissions are a problem. Here is what my /var/mail directory looks like:

barney:/var/mail# ls -la
total 78
drwxrwxr-x 2 bin mail 1024 Jun 10 09:49 .
dr-xr-xr-x 28 bin bin 2048 Sep 26 2003 ..
-rw-rw---- 1 adm mail 28148 Jun 9 23:20 adm
---------- 1 daemon mail 0 Jun 9 16:09 paradigm.lock

Ken: I checked the thread you sent, but it doesn't seem to apply since the lock is being created in /var/mail rather than /usr/bin/mail. Thanks anyway.

Jose: My /etc/rc.config.d/mailservs files is set correctly. I've stopped and restarted sendmail as you suggested. I'm running some tests now to see if the problem is still there.

Thanks...

- Chuck

Re: .lock file in /var/mail is not being removed

Chuck Sims — Thu, 10 Jun 2004 11:52:21 GMT

Aloha All,

It looks like I still have the problem. After stopping and restarting sendmail, I deleted the paradigm.lock file and tried to send a message to paradigm@barney.byu.edu. The following is what showed up in /var/adm/syslog/mail.log:

Jun 10 10:48:31 barney sendmail[22403]: KAA22403: from=, size=597, class=0, pri=30597, nrcpts=1, msgid=<2901020.1086886059248.JavaMail.SYSTEM@alana>, proto=ESMTP, relay=email2.byu.edu [128.187.22.134]
Jun 10 10:48:31 barney sendmail[22404]: KAA22403: SYSERR(root): mailer local died with signal 11
Jun 10 10:48:31 barney sendmail[22404]: KAA22403: to=, delay=00:00:01, xdelay=00:00:00, mailer=local, stat=Deferred

Any further suggestions?

Thanks...

- Chuck

Re: .lock file in /var/mail is not being removed

Sanjay_6 — Thu, 10 Jun 2004 12:00:59 GMT

Hi Check,

Try setting the /var/mail directory permissions to 775 (bin:mail) and see if it helps.

Hope it does.

Regds

Re: .lock file in /var/mail is not being removed

Chuck Sims — Thu, 10 Jun 2004 14:24:50 GMT

Aloha Sanjay,

The directory permissions for /var/mail are already set to 775.

Thanks anyway...

- Chuck