Attachment 1742726 Details for Bug 1911113 – Better (in case of clock skew) patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked

[patch] Better (in case of clock skew) patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked

imap-2007f-lockretry.patch (text/plain), 6.62 KB, created by Albert Flügel on 2020-12-28 15:59:21 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Albert Flügel

Created: 2020-12-28 15:59:21 UTC

Size: 6.62 KB

patch

obsolete

>diff -ur imap-2007a/docs/FAQ.html imap-2007af/docs/FAQ.html
>--- imap-2007a/docs/FAQ.html	2011-07-23 02:20:21.000000000 +0200
>+++ imap-2007af/docs/FAQ.html	2020-12-27 16:27:32.012285692 +0100
>@@ -3404,6 +3404,27 @@
>       <p>The solution to both situations is to replace the client with a good
>       online IMAP client such as Pine. Life is too short to waste on POP
>       clients and poorly-designed IMAP clients.</p>
>+
>+      <p>However, the unix version is a bit more tolerant. When the
>+      server detects, that a lock is set on the mailbox, it retries
>+      to obtain it until 15 seconds after the creation time of the
>+      lock, if the lock is not already that old. Only after this
>+      phase of retrying it sends the "kiss of death" to the competing
>+      process. This way the scenarios outlined above and the related
>+      errors probably displayed to the users are mostly avoided. A
>+      short concurrent access e.g. to check for new mail should not
>+      cause some kind of outage and confuse the users. On the other
>+      side, a short waiting time for the lock to be released should
>+      be acceptable. A particular experience was using the web mailer
>+      "roundcube" (please see http://roundcube.net/ ). It is closing
>+      imap connections by only fractions of a second after opening 
>+      another one yet causing this imap server to detect an existing
>+      lock and requesting the termination of another server instance,
>+      what makes roundcube assume something went wrong. Probably this
>+      shortly later closing of connections is actually a matter of
>+      deferred execution in the browser, who is the actual client of
>+      roundcube in turn, so this phenomenon is probably (unclear) not
>+      even a fault of the roundcube implementation.
>     </dd>
>   </dl>
> 
>diff -ur imap-2007a/docs/FAQ.txt imap-2007af/docs/FAQ.txt
>--- imap-2007a/docs/FAQ.txt	2011-07-23 02:20:20.000000000 +0200
>+++ imap-2007af/docs/FAQ.txt	2020-12-27 16:24:52.166735194 +0100
>@@ -2366,6 +2366,27 @@
>           The solution to both situations is to replace the client with a
>           good online IMAP client such as Pine. Life is too short to
>           waste on POP clients and poorly-designed IMAP clients.
>+
>+          However, the unix version is a bit more tolerant. When the
>+          server detects, that a lock is set on the mailbox, it retries
>+          to obtain it until 15 seconds after the creation time of the
>+          lock, if the lock is not already that old. Only after this
>+          phase of retrying it sends the "kiss of death" to the competing
>+          process. This way the scenarios outlined above and the related
>+          errors probably displayed to the users are mostly avoided. A
>+          short concurrent access e.g. to check for new mail should not
>+          cause some kind of outage and confuse the users. On the other
>+          side, a short waiting time for the lock to be released should
>+          be acceptable. A particular experience was using the web mailer
>+          "roundcube" (please see http://roundcube.net/ ). It is closing
>+          imap connections by only fractions of a second after opening 
>+          another one yet causing this imap server to detect an existing
>+          lock and requesting the termination of another server instance,
>+          what makes roundcube assume something went wrong. Probably this
>+          shortly later closing of connections is actually a matter of
>+          deferred execution in the browser, who is the actual client of
>+          roundcube in turn, so this phenomenon is probably (unclear) not
>+          even a fault of the roundcube implementation.
>      _________________________________________________________________
> 
>    7.20 Why does my IMAP client show all the files on the system,
>diff -ur imap-2007a/src/osdep/unix/unix.c imap-2007af/src/osdep/unix/unix.c
>--- imap-2007a/src/osdep/unix/unix.c	2011-07-23 02:20:10.000000000 +0200
>+++ imap-2007af/src/osdep/unix/unix.c	2020-12-28 16:42:48.433466340 +0100
>@@ -458,10 +458,15 @@
>   int fd;
>   char tmp[MAILTMPLEN];
>   DOTLOCK lock;
>-  long retry;
>+  int kodretry;
>+  int lockretry;
>+  struct stat sbuf;
>+  time_t now;
> 				/* return prototype for OP_PROTOTYPE call */
>   if (!stream) return user_flags (&unixproto);
>-  retry = stream->silent ? 1 : KODRETRY;
>+  kodretry = stream->silent ? 1 : KODRETRY;
>+  lockretry = (kodretry * 100 + 18) / 35 - 2;	/* retries after 350 ms */
>+  sbuf.st_mtime = (time_t) 0;		/* to determine lock age from file */
>   if (stream->local) fatal ("unix recycle stream");
>   stream->local = memset (fs_get (sizeof (UNIXLOCAL)),0,sizeof (UNIXLOCAL));
> 				/* note if an INBOX or not */
>@@ -486,22 +491,42 @@
>   stream->sequence++;		/* bump sequence number */
> 
> 				/* make lock for read/write access */
>-  if (!stream->rdonly) while (retry) {
>+  if (!stream->rdonly) while (kodretry > 0 || lockretry > 0) {
> 				/* try to lock file */
>     if ((fd = lockname (tmp,stream->mailbox,LOCK_EX|LOCK_NB,&i)) < 0) {
>+      if (! sbuf.st_mtime) {
>+	if (! stat (tmp,&sbuf)) {	/* adapt lock retry number */
>+	  if ((now = time ((time_t) 0)) >= sbuf.st_mtime && now - sbuf.st_mtime < kodretry) lockretry = ((kodretry - (now - sbuf.st_mtime)) * 100 + 18) / 35;
>+	}
>+	else sbuf.st_mtime = (time_t) 1;
>+      }
>+        			/* re-try to obtain lock until timeout */
>+      if (lockretry-- > 0) {
>+	if (!stream->silent) {
>+	  if (lockretry >= 0) {		/* implicitely: && kodretry > 0 */
>+	    struct timespec ts;
>+	    ts.tv_sec = 0;
>+	    ts.tv_nsec = 350000000;
>+	    nanosleep (&ts, (struct timespec *) 0);
>+	  }
>+	  else MM_LOG ("Mailbox is open by another process, sending kiss of death",
>+		     WARN);
>+	}
>+	continue;
>+      }
> 				/* suppressing kiss-of-death? */
>-      if (stream->nokod) retry = 0;
>+      if (stream->nokod) kodretry = 0;
> 				/* no, first time through? */
>-      else if (retry-- == KODRETRY) {
>+      else if (kodretry-- == KODRETRY) {
> 				/* learned other guy's PID and can signal? */
> 	if (i && !kill ((int) i,SIGUSR2)) {
> 	  sprintf (tmp,"Trying to get mailbox lock from process %ld",i);
> 	  MM_LOG (tmp,WARN);
> 	}
>-	else retry = 0;		/* give up */
>+	else kodretry = 0;		/* give up */
>       }
>       if (!stream->silent) {	/* nothing if silent stream */
>-	if (retry) sleep (1);	/* wait a second before trying again */
>+	if (kodretry) sleep (1);	/* wait a second before trying again */
> 	else MM_LOG ("Mailbox is open by another process, access is readonly",
> 		     WARN);
>       }
>@@ -518,7 +543,8 @@
>       }
>       ftruncate (fd,i);		/* make sure tied off */
>       fsync (fd);		/* make sure it's available */
>-      retry = 0;		/* no more need to try */
>+      kodretry = 0;		/* no more need to try */
>+      lockretry = 0;
>     }
>   }
>

Actions: View | Diff

Attachments on bug 1911113: 1742305 | 1742307 | 1742726