Subject: Again on dot-locks

From: Federico Giannici <[email-masked]>
Date: Thu, 26 Aug 1999 15:27:12 +0200

Mark Crispin wrote:
> 
> On Tue, 24 Aug 1999 16:07:03 +0200, Federico Giannici wrote:
> > >From time to time (about a couple times a day) a dot-lock file remains
> > into the /tmp directory while the associated process no longer exists.
> > Obviously this is really bad because the user can no longer read his
> > email...
> > 1) Is this behaviour normal? What I could try to solve it?
> 
> No, it is not normal for a user to be locked out.

The problem persists (2-3 times a day), so I made some investigations.

I discovered that, when this happens, the client didn't logged out
correctly (no "Logout user=..." syslog message).

Can it be useful to find the problem?
What else I can do to find the problem?

Thanks,
___________________________________________________
    __
   |-                      [email-masked]
   |ederico Giannici      http://www.neomedia.it

        Amministratore unico - NEOMEDIA sas
___________________________________________________
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Thu, 26 Aug 1999 09:42:45 -0700 (PDT)

> correctly (no "Logout user=..." syslog message).

I'm not surprised; this is is usually how stale lock files are left lying
around.

The next time this happens, try running imapd from a shell logged in as the
user, and give the command "x select inbox" to it.  Then, send me a transcript
of what subsequently happens.  For example:
 * PREAUTH neomedia.it IMAP4rev1 v12.256 server ready
 x select inbox
 * 43 EXISTS
 * 2 RECENT
 * OK [UIDVALIDITY 2132] UID validity status
 * OK [UIDNEXT 33251] Predicted next UID
 * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
 * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Draft \Seen)]
 x OK [READ-WRITE] SELECT completed

---

From: Federico Giannici <[email-masked]>
Date: Thu, 26 Aug 1999 19:04:51 +0200

Mark Crispin wrote:
> of what subsequently happens.

I have to issue that commands when the stale lock file is still there,
without deleting it?

To temporarely solve the problem, I have written a little script that
every 5 mins check if there are any lock files and delete them if the
associate process is no longer running. Have I to suspend this script?

If it is not necessary, here it is the result of "x select inbox" for a
user for which today a stale lock was found:

* PREAUTH aragorn IMAP4rev1 v12.256 server ready
x select inbox
* 2 EXISTS
* 2 RECENT
* OK [UIDVALIDITY 935325743] UID validity status
* OK [UIDNEXT 51] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)]
Permanent flags
* OK [UNSEEN 1] first unseen message in /var/mail/fici
x OK [READ-WRITE] SELECT completed
x logout
* BYE aragorn IMAP4rev1 server terminating connection
x OK LOGOUT completed

Thanks,

---

From: Mark Crispin <[email-masked]>
Date: Thu, 26 Aug 1999 10:08:47 -0700 (PDT)

That transcript that you sent was perfectly normal.  The new imapd was able to
acquire a read/write session without any problems.

What problems are you seeing?  What error messages are you getting when the
problem happens?  How does your every-5-minutes script decide if a lock is
stale or not?

Perhaps you need to suspend your script, in order to do an imapd transcript
that demonstrates the problem.

---

From: Federico Giannici <[email-masked]>
Date: Thu, 26 Aug 1999 19:40:04 +0200

> acquire a read/write session without any problems.

This is because i deleted the stale lock file...

> problem happens?

When a stale lock file remains into /tmp then the corresponding user
isn't able to access its mailbox any longer...

> How does your every-5-minutes script decide if a lock is
> stale or not?

If no process exists with the pid written into the lock file, then the
script argue that the lock is stale!
To be sure, it also makes a second check after 5 secs.

> that demonstrates the problem.

OK, I'll do...

Bye,