Atro Tossavainen <[EMAIL PROTECTED]> writes:
> Date: Fri, 02 Nov 2007 11:22:50 +0200
> To: [email protected]
> From: Atro Tossavainen <[EMAIL PROTECTED]>
> Subject: Re: [OpenAFS-devel] YDL 5.0.2... it gets weirder
>
> I wrote a while ago:
>
> > > > Now that I look at that file, it makes perfect sense - it's included
> > > > for Alpha, AMD64 and s390x Linuxes already.
> > >
> > > And does life get better?
> >
> > FSVO thereof. The run-time linker doesn't complain about being unable
> > to load pam_afs.so any more. It loads and "debug"s nicely, it just
> > doesn't work. I've tcpdumped the traffic on the problem host and it's
> > not talking to the AFS servers.
> >
> > I attached a strace to the login process and it seems to be going through
> > the motions all right, but it segfaults at the end. The same also
> > happens with klog, it just segfaults as before. I need to check that
> > the strace logs don't contain anything that could be used to compromise
> > our systems and then I can post them.
>
> Here they are, finally.
>
> http://www.biocenter.helsinki.fi/~atossava/pam_afs.so.txt
> http://www.biocenter.helsinki.fi/~atossava/klog.txt
Those don't say much - just that it died soon after doing something
strange with ldap.
What would be more interesting is a stack backtrace and
general machine environment at time of crash.
2 ways:
via core dump:
sh
ulimit -c unlimited
/usr/src/openafs-1.4.3/ppc_linux26/dest/bin/klog -setpag userid
...
gdb klog core
via debugger
gdb /usr/src/openafs-1.4.3/ppc_linux26/dest/bin/klog
run -setpag userid
in both cases:
where
info r
x/30i $pc
If you built with "-g", you may also be able to
look more easily at additional program state information.
At a shear guess, it looks like you're loading /lib/libcom_err.so.2.
Where does this come from?
That could cause interesting behavior, especially on 64-bit machines.
-Marcus Watts
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
