Subject: imapd upgrade, mailboxes back in time

From: Nicolas Kowalski <[email-masked]>
Date: Thu, 16 Oct 2003 18:30:09 +0200

Hello.

I upgraded today my imap server (GNU/Linux) to imap-2002e. When I
tried to install the new imapd and ipop3d binaries in /usr/local/sbin,
the system complained with a "text file busy", because it was handling
some IMAP connexions; fine. So I decided to stop currently running
imapd processes to be able to install the new binaries:

- edited /etc/inetd.conf and commented out imap/pop lines,

- pkill -HUP inetd

- pkill imapd   (<= here's my error)

- installed new binaries

- edited back /etc/inetd.conf

- pkill -HUP inetd

Apparently all went fine, but in fact, some of the users using
Mozilla, Netscape, Eudora or OE found their mailboxes in the state
corresponding to hours or days back (probably when they last started
their IMAP client, or did the last expunge).

My question is : how can I stop the IMAP processes on the server, and
keep the mailboxes consistent ?

Thanks.

-- 
Nicolas

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

---

From: Chris Hartmann <[email-masked]>
Date: Thu, 16 Oct 2003 18:42:42 +0200 (Westeuropäische Sommerzeit)

> keep the mailboxes consistent ?

You should probably mv imapd imapd.old; then install and write a mail to
your users to make them disconnect and reconnect.

> Thanks.

Chris

---

From: Mark Crispin <[email-masked]>
Date: Thu, 16 Oct 2003 09:48:19 -0700 (PDT)

> keep the mailboxes consistent ?

The answer is: don't stop the IMAP processes.  Let them continue to run.
You'll generally do more harm by stopping them than you will by letting
them run the old version.  If you absolutely must stop an IMAP process,
sending it a HUP signal is better than some other way.

The correct thing to do is just to replace the binaries.  Instead of
trying to overwrite the old binaries (which you can't do because of the
"text file busy" condition), either rename or delete the old binaries then
install the new ones.

For example, here is what I do.  This may be a bit more elaborate than
what you want, but it will give you the general idea.  You don't have to
copy this verbatim (in fact, you shouldn't!!) but rather just use it as an
example of a real-life sysadmin maintenance of the imapd binary.
	rm imapd.new imapd.oold
	cp /usr/src/imap-2003/imapd/imapd imapd.new
	mv imapd.old imapd.oold
	mv imapd imapd.old;ln imapd.new imapd

imapd.new is always the "new" version and is generally the running
production version.  imapd.old is the "old" version for possible rollback
if the new version has a problem, and imapd.oold is the second older
version.  A rollback is accomplished with:
	rm imapd;ln imapd.old imapd

Note that I do the actual replacement of imapd (a two instruction process)
in a single command line.  That's to minimize the amount of time that
there isn't an imapd binary.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Nicolas Kowalski <[email-masked]>
Date: Thu, 16 Oct 2003 18:57:58 +0200

>> imapd processes to be able to install the new binaries:

[...]

> your users to make them disconnect and reconnect.

You are right ; this is much simpler, and do not involve killing imapd
processes, which caused these damages.

Thanks for your reply.

-- 
Nicolas

---

From: Nicolas Kowalski <[email-masked]>
Date: Thu, 16 Oct 2003 19:02:44 +0200

> sending it a HUP signal is better than some other way.

I was not aware of this fact. I'll keep it in mind for later
maintenance.

> there isn't an imapd binary.

I know how to do a clean upgrade now. :-)

Many thanks for your reply.

-- 
Nicolas

---

From: "Chr. von Stuckrad" <[email-masked]>
Date: Thu, 16 Oct 2003 19:34:19 +0200

> 	mv imapd imapd.old;ln imapd.new imapd

Normally in UNIXes I do this as:

        ln imapd imapd.old
        ln imapd.new imapd.mv
        mv imapd.mv imapd

This way you have NO point in time, when there is no imapd.

First you make a link to keep the old version for rollback,
then you make a link from the new to an arbitrary new name,
then you 'mv' the arbitrary name to 'imapd', which normally
just drops the running versions file into oblivion,
but THAT version will live on as the first link.

Most UNIXes forbid to *write* on a busy program,
but 'mv' will *implicitely* 'rm' the old name atomically.

Stucki

---

From: Mark Crispin <[email-masked]>
Date: Thu, 16 Oct 2003 10:44:46 -0700 (PDT)

> Normally in UNIXes I do this as:

That's a good strategy if it works.  However, I've encountered UNIX
variants in which a busy text file can not be the destination of a rename.

It was strange, since it allows the busy text file to be renamed and even
unlinked.  But it does not allow rename to do an implicit unlink.  I
forget which UNIX variant does that.  I made a conscious effort to forget.

-- Mark --