Re: [cobalt-users] Re: Perpetual mail locks on Qube2

[Larry Smith <lesmith@xxxxxxxxx>]

INRE [cobalt-users] Re: Perpetual mail locks on Qube2:
> | - Turn off email services in Cobalt Admin
> | - Telnet as root:
> |      rm /home/spool/mail/.*.pop -i
> |      rm /home/spool/mail/*.lock -i
> |      rm /var/cobalt/status
> | - Reboot server in Cobalt Admin
> | - Restart email services in Cobalt Admin
> |
> | Everybody is happy again.
> |
> | Grant
>
> Hi list
> I have exactly the same problem on my Qube 2.
> I've solved it by removing the .pop and .lock and reboot
> But after 5 or 6 days, the problem was back.
> It seems that the problem in comming from a qpopper update with OS 4.0.
> I'm stuck with this problem.
> Please help

Grant, Alain, et al....

  First I will state that I do not have a Qube2.......

But, some basic "trouble" shooting would seem in place here.

Presuming, based on documentation, etc that the qpopper program is creating 
the lock and pop files in response to a connection from "that" user/account - 
and reading on in the docs, these are supposed to be removed when the 
connection is closed.

To my point - have any of you done some "back-tracking" - EG:  identify a 
lock / pop file that exists  then look for the last time that user read mail 
(from your logs), then identify (netstat -an ) if there is any connection 
still showing for that last IP that the user read mail on.  _OR_ look through 
the logs and see if there is anything like "lost connection from" regarding 
that IP and user.

Reason I mention this is that I have seen a similar problem even under ipop3d 
on other *nix systems - and it generally relates back to a "flaky" network - 
either on the server end or the customer end causing the connection to 
suddenly "disappear" out from under the qpop or ipop program.

You might also do a "ps fax | grep qpop" and see if there are any of these 
processes "hanging" around as it were - also a syptom of a flaky network 
somewhere along the line.  If the qpop program is not "seeing" the close, 
then it will hang around watching for anything to tell it to go away.

Larry Smith
SysAd ECSIS.NET
sysad@xxxxxxxxx