On 03/02/07, Jaakko Niemi <[EMAIL PROTECTED]> wrote:
On Wed, 24 Jan 2007, Brian Brunswick wrote:
> Package: sfs-server
> Version: 1:0.8-0+pre20060720.1-1
> Severity: grave
> Justification: renders package unusable
>
>
> While sfs-client seems to work ok onto another server, I get sfsauthd
crashing
> out and exiting leaving the above message in the syslog, when I do:
> sfskey register
> while trying to set up a server. (after sfskey gen)
Sorry about the delay, I've been awfully busy with work.
No problem - I've been away as well.
For starters, please do shut down the server, and start sfssd manually
with -d switch, and see if any additional information is outputted.
Not much use I'm afraid...
LKG8A754B:~# sfssd -d
sfssd: version 0.8pre, pid 9479
sfssd: listening on TCP port 4
sfsrwsd: version 0.8pre, pid 9481
sfsauthd: version 0.8pre, pid 9480
sfsauthd: dbcache_refresh_delay = 0
sfsauthd: Disabling authentication server cache refresh...
sfsauthd: serving @nslu2.internal,pv5tbuysggfb3322r5wbs4v6mg9xzpk3
sfsrwsd: serving /sfs/@nslu2.internal,pv5tbuysggfb3322r5wbs4v6mg9xzpk3
sfsauthd: fatal: Should not be reached
sfssd: EOF from /usr/lib/sfs-0.8pre/sfsauthd
This seems unreproducible on other platforms, and given that the
authentication function just runs to the end, I'm thinking that something
(PAM or shadow) broke on ARM. Do you have possibility to rebuild sfs
on your machine? (quite a few hours and >500mb of disk needed..)
--j
Well, the machine in question is a 32MB nslu2, and it has difficulty even
running dpkg with todays database sizes! Mad swapping, sometimes onto a usb
key!:-( Can you say low expected lifetime?
However, I did manage yesterday to get debian etch installed with an
nfs-booted qemu instance, so things are looking up.(Minor fights with duff
mirrors and using vde2 being different from vde on the web page I was
following, and /dev/console missing etc. Might be worth putting my notes up
somewhere.) Its slow, but at least its not swapping to death. It looks like
its going to build - I'll leave it overnight :-)
I've just looked at the code, and at least that message only appears once.
Its also a bit suspicious - theres something that sets
pwd to NULL possibly further up. I can't help wondering also if somehow I
managed to trash the config files, or be weird by running as root (but it
does have a password) or something! I'm going to try purging all the config
and re-installing sfs from scratch, just in case.
Hmm... running dpkg on an nfs-mounted chroot inside qemu (256M memory set)
is much faster :-)
But running apt is slower! apt is busy-waiting on a 1ms loop waiting for
dpkg output. Its taking actually taking most of the cpu. I feel another bug
report coming on.
Anyway, its late here, more news another day. I'll just verify the bug with
a clean config, and then maybe bung in some traces and find out
whats going on with that suspicous auth function.
--
[EMAIL PROTECTED]
