On Tue, 5 Jun 2007, Wolfgang Pfeiffer wrote:
Not very helpful, can you provide a strace of the failing command ?
Strace is attached.
Eep, can you redo that with strace -f (to follow the child)?
the only help this gives is:
waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG) = 10626
but we already knew that was the failure mode :)
No problems with 8.13.8-3, except the one that annoys all
latest sendmail versions, when running 'sendmailconfig':
makemap: /etc/mail/authinfo.new.db: line 4: key authinfo:mail.[removed].de:
duplicate key
And which of those duplicate keys is getting use for your authentication
information? I hope they are the same - in which case, why is it
duplicated ?
No, they're not the same: 2 different mailboxes: 2 different user
names, and both have their own authentication passwds. But these accounts
are using the same smtp server, so that's probably why sendmail is
complaining about a duplicate key.
Exactly
Here's how the relevant lines in
/etc/mail/authinfo currently look like - sort of (after changing "mail .."
(in my first message) to "smtp ..." server name, as "mail .." was
wrong ...) :
AuthInfo:smtp.[sameserver].de "U:userone" "P:passwordone" "M:PLAIN LOGIN"
AuthInfo:smtp.[sameserver].de "U:usertwo" "P:passwordtwo" "M:PLAIN LOGIN"
Wrong syntax?
No, I think it is just an misunderstanding of how the feature works.
Please peruse /usr/share/doc/sendmail/cf.README.gz, especially the
section 'Providing SMTP AUTH Data when sendmail acts as Client'
That info, coupled with the fact that access/authinfo are keyed by
name/IP means that will only ever actually use one of those entries.
Sendmail does not save the credentials from server mode (receiving
mail) and re-use them when in client mode (sending mail) - that would
make coattailing, connection caching, etc. worthless.
So you really only have one client->server authentication ID - ie, for
my systems, I do user based authentication for receipt and relaying,
and use authinfo to verify one sendmail server to another - which also
then allows relaying (since the server is trusted).
I also wonder why there are several authinfo.db in here:
/etc/mail/authinfo.db and /etc/mail/authinfo.new.db
Right, had the update worked (no makemap errors), you would only see the
one 'authinfo.db' file... To make sure files don't get trashed, the
makefile always creates a new file, and once convinced it is good, moves
the new file to the old (proper) name.
Not a (to me) known problem, but please make sure you are upto date
maintenance wise (my machines are all running sid, not testing).
I'm running unstable. With the usual procedure: some packages can't be
updated at times, for missing dependencies. Which will then be done
later when dependencies are fine. But now most of the packages on this
machine should be relatively fresh ...
Unstable, interesting - my ppc box is also running unstable, but with a
64bit kernel; the libraries and binaries are the same on both our boxes -
32bit for the most part.
So I'm kinda at a loss as to why you see the failure and I don't :(
Still anything that comes to mind that might be missing here for this
new sendmail-version?
Not yet, the trace will hopefully help alot... though, iirc, you are
running a custom built kernel; can you possibly try with a stock Debian
kernel (they come in 32/64 bit UNI/SMP, and even a Prep).
Failing trying another kernel, what Debian kernel would get me the
closest to your setup?
It is possible that sendmail's use of timers, or other assumed Linux
features could cause breakage on a kernel that doesn't support that
feature.
--
Rick Nelson
<edLin> LWE?
<edLin> Linux W?? E??
<seeS> will eatyou
<JHM> World Expo?
<edLin> i see
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
