On Wed, Mar 27, 2002 at 11:05:33AM +0000, Philip Hazel wrote:
| On Tue, 26 Mar 2002, dman wrote:
|
| > 2002-03-26 18:11:11 16piyF-0006OL-00 failed to open DB file /var/spool/exim/db/retry: File exists
| > 2002-03-26 18:20:33 16q1AX-00020S-00 failed to open DB file /var/spool/exim/db/wait-remote_smtp: File exists
|
| Can you provide a prescription for that?
The best I can say is to compile exim4 (either 4.00 or 4.01) and for
installation simply "cp build/exim /usr/sbin/exim". I saw this too on
the other machine I did that on, but didn't pay too much attention to
it (that machine also had some problem with the lockfiles; removing
them and recreating them with 'touch' seemed to solve it, but that
system is half-dead at the moment and I can't do anything with it).
| It's an error that people report from time to time, but which I've
| never been able to reproduce in any way.
Ok.
| > I didn't do an exactly kosher install, though. I simply put the
| > exim4 in place of the exim3 one (keeping a backup copy).
|
| Has your DBM library changed since you compiled Exim 3?
I didn't think so ...
For exim3 I was using the debian package. exim4 I compiled myself,
and didn't expect anything to be different. Hmm, exim (the package)
doesn't depend on libgdbmg1 (the package) at all. The libraries the
exims need are :
$ ldd /usr/sbin/exim3
libident.so.0 => /usr/lib/libident.so.0 (0x40020000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40023000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4002c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40041000)
libpam.so.0 => /lib/libpam.so.0 (0x4006e000)
libdb2.so.2 => /lib/libdb2.so.2 (0x40076000)
libresolv.so.2 => /lib/libresolv.so.2 (0x400b7000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x400c8000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x400ef000)
libc.so.6 => /lib/libc.so.6 (0x400f9000)
libdl.so.2 => /lib/libdl.so.2 (0x4021b000)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4021f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /usr/local/sbin/exim4
libresolv.so.2 => /lib/libresolv.so.2 (0x40020000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40031000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40046000)
libdb3.so.3 => /usr/lib/libdb3.so.3 (0x40073000)
libpq.so.2 => /usr/lib/libpq.so.2 (0x4011b000)
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4012c000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x40159000)
libc.so.6 => /lib/libc.so.6 (0x4021b000)
libdl.so.2 => /lib/libdl.so.2 (0x4033d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
| If Exim 4 was compiled with a different DBM library version, that
| might explain it.
Hmm, is db2/db3 the DBM library? If so then you've pegged it.
| > Hmm, if I use the 4.01 exim_dumpdb, it says (abbreviated)
| > "Failed: Success". If I use the 3.34 one I get an outdated list of
| > entries from the retry db.
|
| That *does* look as though the DBM library has changed.
Sounds like that's the prescription for recreating the error :-).
| > Should I remove the existing db files or is there a command I
| > should use to fix them?
|
| If it is a change of library, just remove them and let them be
| recreated.
I did that, in addtion to properly installing the rest of the
binaries, and I no longer see that error message.
Due to a little blunder of mine, as I installed the exim 3.35 package
immediately after properly symlinking all the exim_* binaries. (I
didn't pay enough attention when apt-get upgradeing and hadn't put
exim on hold yet. It won't happen again :-)) Somehow I managed to
get *two* /var/spool/exim/db/retry and *two*
/var/spool/exim/db/wait-remote-smtp files! I didn't think that was at
all possible. I blew away the whole db directory (I couldn't remove
both of the files; rm said the second one didn't exist though ls said
it did). Now the problem is gone.
-D
--
Thy Word is a lamp unto my feet
and a light unto my path.
Psalms 119:105
