Kelli Wolfe wrote:
>
> Hello Michael,
>
> Thank you for your offer of assistance, I'm in need: that trace file
> is huge.
I told you about that. But doesn't matter.
> I've attached it. This is from the machine I'm trying to telnet into.
> There are a few things in this file that I'm unsure about.
> First, there's a 1000+ close(xxxx) ..... (Bad file descriptor) messages.
This is normal. Some application (that should be login) tries to close
all possible opened files (should be 1024-3 calls). The simplest way of
that is just close 'em.
> Next there are several "Connection refused" messages, I'm not sure
> if they have anything to do here or not.
Probably not -- I can guess that the libc tried to connect to local
nscd (name service cache daemon); if it isn't running, libc will
fallback
to do the work itself.
> And lastly, there is a "--- SIGSEGV (Segmentation fault) ---".
And most interesting really. Unfortunately, this is what I expected
to see. My guess was that (pamified) login (or one of pam modules,
or pam itself) just have trouble/bug somewhere that caused SISSEGV or
something similar to occur. I was just not shure about that, as
telnetd exits with 1 (according to your logs), but that's normal.
Oh, ma, just some trivial bug/typo somewhere... But this is from
things that are very hard to investigate remotely....
> ------------------------------------------------------------------------
> Name: trc.tar.gz
> trc.tar.gz Type: Unix Tape Archive (application/x-tar)
> Encoding: base64
> Size: 17143 bytes
Unfortunately (second time in this letter) I can't read this file:
$ gzip -t trc.tar.gz
gzip: trc.tar.gz: invalid compressed data--format violated
$ _
And the file really looks "strange" at least. I guess that your
"Microsoft Outlook 8.5, Build 4.71.2377.0" just screwed it up...
You can resend it (maybe using some real mailer instead), but I
think that it is not necessary anymore. We need to find where
that sigsegv occured, and strace really can't help here.
Unfortunately (3rd time!!!) RedHat strips all binaries, so it
is not really possible to find where problem occurs.
As I guess, you are not a "unix guru" (or at least not a "unix
programmer guru"). But still can suggest you to do the following.
1. Enable (temporary) core dumping from your daemons (redhat by
default forbids cores from daemons). You can enable that two
ways -- commenting out a line with 'ulimit -c 0' in /etc/rc.d/
/init.d/functions (if I remember correctly), or replacing
your login by little wrapper (but be very careful, and check
that 'linux single' lilo command works before doing this):
rename /bin/login to /bin/login.save
create /bin/login with the following contents:
#! /bin/sh
ulimit -c 100000
exec /bin/login.save $*
and make it executable (chmod +x /bin/login)
2. Try to login again. You should get core now, probably in /.
Use 'gdb /bin/login /core' and look if it can tell you
something useful (use "bt" command). Information needed is
a name of a module (most important) and function/linenumber of
a place where that sigsegv occured.
3. If that does not shows anything, you need to recompile some
packages/libraries used so that them have debugging info.
And repeat step 2.
All of that is a work for package maintainers/authors (esp. if
user have no big expirience with all that stuff). But problem
is that we can't tell _what_ package is in bad. It is definitely
not telnet/telnetd. It may be login, pam or one of pam modules.
Also, try asking other people -- e.g. behind pam_ldap and/or
login.
Or your can ask someone with programming expirience near you
to help you to do so.
I CC'd this message back to pam-list.
Regards,
Michael.
