Re: Puzzling pop lock files

Hi Randall (and all),

I uninstalled qpopper 4.0.5 and installed qpopper 4.0.8 today. It's working 
fine. You asked me to post to the list to let you (and others) know if it 
solved my problem. To refresh everyone's memory, I'll quote what  I 
originally posted as being my problem:


> I had a mail server crash on Monday of this week so I hurriedly set up
> another FreeBSD box I have to accept email in place of the crashed 
> machine.
> The new box  already had Sendmail installed but didn't have a POP3 server 
> so
> I installed Qpopper 4.0.5 from the ports.
>
> In the past, I've had occasional problems with pop lock files that, for 
> one
> reason or another, didn't want  to go away. And of course, when a customer
> attempts to pop mail  while a pop lock is present for his mailbox the
> customer gets a "password error" on his end and on our end I get logged 
> the
> message "Is another session active?".  This is just the way it's always
> worked and it's my understanding that this is  how it's supposed to work
> :-)
>
> That's why I'm perplexed at what I see on this new box I set up on Monday.
> Pop locks are staying around, but they are NOT preventing anyone from 
> being
> able to pop their mail.  There are  some pop locks  on this machine now 
> from
> Monday, yet these customers are happily popping their mail today.
>
> Why is this? I must of overlooked something perhaps in my haste to  get 
> this
> setup, but it's been awhile since I've set up a new Qpopper and I don't 
> know
> what I've overlooked.

I've now found that what I thought of as a "problem" is not a problem at all 
but a feature. And a quite useful one at that. The lock files I was seeing 
(.username.pop) files at the top of /var/mail must be the temp drop files 
(as you Randall suggested) and not lock files at all which is what I thought 
they were. That's why customers with a .username.pop file were still able to 
pop mail despite the presence of these files. Which brings up a question: 
what does a pop lock look like as opposed to a temp drop? Let me show an 
example (which is where my confusion stems from):

I have another mail server running Sendmail/Qpopper on Red Hat linux. When I 
set this one up I did not pass --enable-keep-temp-drop as a configuration 
option because I was unaware of this particular option. Right  now a 
customer is popping mail. If I do a ls -al on /var/mail, I see this while 
the customer is popping:

-rw-rw----    1 gwilson  mail            0 Mar  3 15:57 gwilson
-rw-rw----    1 gwilson  mail       115869 Mar  3 15:57 .gwilson.pop

Are you saying that the .gwilson.pop file is a temp drop as opposed to a pop 
lock? Lets suppose gwilson is using Outlook Express (as a vast majority of 
my customers do). Lets also suppose that, for whatever reason, gwilson's pop 
session was aborted prematurely. My experience over the past few years is 
that in such a scenario the .gwilson.pop file is likely to hang around for 
10 to 15 minutes and until this file goes away if gwilson attempts to pop 
mail again on his end he gets what appears to him to be a password error, on 
my end I get logged:

Mar  3 16:12:09 Raydeus-Dee popper[11648]: gwilson at 64.xx.xx.xx 
(64.xx.xx.xx): -ERR [IN-USE] /var/mail/.gwilson.pop lock busy!  Is another 
session active? (11)

This happens whenever there exists a gwilson file (the mailbox) and a 
.gwilson.pop file simultaneously.  I have noticed the following in /var/mail 
from time to time:


-rw-------    1 hostmast mail     683814 Mar  1 10:02 hostmaster
-rw-------    1 hostmast mail           16 Mar  3 15:57 hostmaster.lock
-rw-rw----    1 hostmast mail     268934 Mar  3 15:58 .hostmaster.pop

 I don't get to see this often because when someone first starts to pop mail 
these three files exist together only very briefly, then there is just the 
username and the .username.pop file until the pop3 session is over. So the 
username.lock file is the pop lock whereas the .username.pop file is a temp 
drop? And if I had used --enable-keep-temp-drop when I set up this qpopper 
the .username.pop files would not go away but would persist as  zero byte 
files thus allowing me to see when this user last popped his mail? (Quite 
useful, I had been using ls -lut to determine this which may or may not be a 
very accurate way of doing it).

So if I see a .username.pop file that is something other than zero byte 
size, that user is actively popping mail and if for whatever reason attempts 
to pop it again while that file is there, there will be an error, but if a 
.username.pop file of zero byte size is present the user can pop his mail 
ok?  My server logs this error as ERR [IN-USE] /var/mail/.gwilson.pop lock 
busy! which is why I thought the .username.pop files were the pop locks.

Am I getting a correct understanding of how this all works now?

Thanks so much.

Lisa Casey