debugging ideas? login problems...
I'm just looking for debugging ideas for a problem I'm having logging into my
nslu2. I've got two drives - a 1 GB usb flash drive that is unslung to on port
two (top most USB port), and a 750GB HD that actually is the file server. I'm
running a second thttpd (renamed to my_thttpd) on another port. Other than
that, it's mostly stock.
I can use the samba shares and the extra thttpd without any problems. And I've
been using putty to ssh in over the last few days to work on the web page that
it serves. But a few days ago, I noticed I couldn't ssh in. I tried to telnet
in, and the connection would accept my password, then immediately close. I
powered down, rebooted with only the flash drive in port 2 and could telnet in
(after enabling it, of course). I looked around and everything seemed normal.
I noticed I hadn't put .ext3flash in /, so I added that, then rebooted with
The system came up and worked fine for a couple days. But this morning, I
noticed I can't ssh in any more.
- I realized I forgot a detail: Unslung V2.3R63-uNSLUng-6.8-beta
copied from the telnet motd screen. after telneting in, the machine
prints the motd, then just hangs like it can't start the shell...
- Sounds like one of your disk has a corrupted file
system. I had similar symptoms.
How to check and fix
- Possible solution: swap space.
I was unable to login to my slug after a short while of running, despite other
programs being functional.
At a guess, I figured that turning off the swap space might have been
responsible. If no new applications could be made, then the login would work,
but a shell could never be spawned.
So I created a swap file on my harddrive (the one I would like to mostly stay
spun down). So far, a few days have passed and I haven't had any problems. So
I think this might have fixed it.
One question: what's the best way to tell how much memory is free on the slug
(and how much swap space it's using)? I worry that using top is too large...