For a while now I've had this problem. I thought it was hardware, but I
keep switching around the hardware, and wherever SlimServer goes, the
problem follows (and more importantly, when SlimServer goes away, so
does the problem).
I'm using SlimServer 6.5.1 on SuSE 10.2 (was 10.1 with same sympto
CatBus;192928 Wrote:
> So now I'm finally looking at /tmp/slimserver.log and perhaps every time
> the server dies, there are one or more lines in the log that say "no
> space left on device". Aha, disk crash!
Well, it thinks something has run out of disk space. If you installed
from the RPM, t
I can do that (not at the moment). /usr is on /. I wonder if this
could perhaps be a ulimit problem? I've never worked with ulimit
before but I believe SuSE has been using it by default since ~10.1.
--
CatBus
CatBus's P
Also check where /tmp and /var/tmp are located - lots of CPAN stuff uses
/tmp.
--
bpa
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=342
Are there any related messages in /var/log/syslog and /var/log/messages?
(although I'm not familiar with SuSE specifically so these may not be
the exact paths to the system logs). '$sudo dmesg' might be helpful
too.
Ed
--
ehjones
>From slimserver.log:
2007-03-27 19:21:00.3204 UPnP: Error adding multicast membership, UPnP
may not work properly: Protocol not available
2007-03-27 19:21:00.3380 UPnP: Error setting multicast TTL: Protocol
not available
2007-03-29 13:11:39.6676 About to look for files in
/home//Documents/Music
For what it's worth, I've seen the occasional run of "no space left on
device" messages in my Gentoo box's slimserver log. These have not been
associated with any obvious server malfunction, and I most definitely
have not run out of space in any of the drive's partitions, and have
stacks of free R
Thanks--any info is helpful. My music is transcoded to FLAC by
SlimServer for playback, so the files may be large, but I imagine it's
not a "weirdly encoded file" problem. May just be a general decoding
problem, I suppose.
Still, I'm hoping it was SlimServer running into the SOFTFDLIMIT. I
can
CatBus;193969 Wrote:
> Thanks--any info is helpful. My music is transcoded to FLAC by
> SlimServer for playback, so the files may be large, but I imagine it's
> not a "weirdly encoded file" problem. May just be a general decoding
> problem, I suppose.
>
> Still, I'm hoping it was SlimServer ru
You might also want to check the number of free inodes on each of your
filesystems...
(That's a wild stab in the dark, but it's the best I can think of!)
Matthew
--
mflint
'Clicky-woo linky'
(http://www.insignificant.org/wiki/index.php/Slim_Plugins) to web page
of my plugins
I'm starting to think that the mystery death is not remotely related to
the messages in the log file. The "no space left on device", etc are
just periodic messages from the client or somewhere, and those problems
are nonfatal and worked around when they are encountered.
I'll check the other thin
Are you sure it is not /tmp filling up?
If /tmp gets full, you can have serious problems... and it will be
wiped clean on reboot, so you won't see anything there to explain just
what it was that got full.
--
snarlydwarf
s
I'm not sure of anything ATM. What I know on this subject: /tmp has
15GB of free space, and that amount stays more or less constant when
there are no problems (i.e. it seems everything is cleaning up decently
after itself). Whether something suddenly spikes /tmp usage and fills
it with 15GB of d
CatBus;193990 Wrote:
>
> However, that does bring up an interesting point. If rebooting the
> server always brings it back after it suffers an episode, I could
> schedule a periodic "therapeutic/preventative reboot". Just like
> managing a Windows server...
Flawed logic.
That would apply in
Good to know that the SB itself can't log to the server--so that means
"no space left on device" means SOMETHING server-related.
Regarding reboots, remember the server is headless and inbound network
connections no longer work when the problem happens, so an automated
reboot is friendlier (though
CatBus;194026 Wrote:
>
> Regarding reboots, remember the server is headless and inbound network
> connections no longer work when the problem happens, so an automated
> reboot is friendlier (though admittedly perhaps not timelier) than what
> I have to go through for a manual reboot. If SlimSer
Oh, yeah, and totally outside of Slimserver..
I have a laptop. It's now 7 years old and sort of tempermental, but it
works for what I need it for (being able to login to servers at work
even if I am out of town... some day I will be able to have a real
vacation where I can toss the cellphone int
snarlydwarf;194051 Wrote:
> But it wouldn't fix anything...
Manual reboots do solve the problem (I thought I mentioned this earlier
but may not have). i.e. it's broken, then I reboot, then it's not
broken anymore. So I'm just automating an existing manual process that
I do when SlimServer dies
CatBus;194064 Wrote:
> My server has been obnoxiously well-behaved for the past few days, so
> there's nothing to see.
It knows you are watching it.
The trick is to sneak up on it.
When you are bored (and it is not looking):
du /tmp
du /var/tmp
du /var/log
Look for something growing or susp
Officially getting pissed off now.
Okay, so it happened again...kinda. The server seems fine, but I'm
trying to transfer files to it and BAM down goes the connection. So I
actually manage to NX into the box (surprise!) and am able to confirm
that / has 15GB free, before BAM, it drops again. Th
CatBus;194516 Wrote:
>
> Okay, so it happened again...kinda. The server seems fine, but I'm
> trying to transfer files to it and BAM down goes the connection. So I
> actually manage to NX into the box (surprise!) and am able to confirm
> that / has 15GB free, before BAM, it drops again. Then
I'm quite open to the idea that we have more than one problem going on
simultaneously here.
Some more information, if it's relevant. I do all network testing
wired. If wireless is flaky, well, use wired. That's what it's there
for.
The packets were indeed from 255.255.255.255, which made me t
All memory checks out OK (man is that a long test!)
I replaced the router--it needed killing anyway. No problems so far,
but that doesn't mean much. Here's the list of devices on the
network:
Server with Marvell gigabit card (also has unused onboard Intel
10/100)
Desktop with SiS onboard 10/10
CatBus;194976 Wrote:
>
> We'll see how this flies. If things behave themselves, this has been
> the most bizarre router death I've ever witnessed.
I dunno, I have some neat ones from both a Belkin and a Netgear... the
Belkin was especially fun:
I could ssh into my linux machine from work
but S
snarlydwarf;194999 Wrote:
> they never ever did a software upgrade... that they just didnt care: if
> it was broken, "go buy a new one" was easier for them than actually
> maintaining code and updates
That's why I pretty much require a home router that's supported by
DD-WRT--at least I know it's
A complete week hasn't gone by, but I'm increasingly confident that the
new router did the trick. The old router is now being moved from my
spare parts bin into the trash.
All I can figure is that the disk space messages must have been caused
by log files on the server filling up the disk due to
I knew it I knew it I knew it!
Posting that last comment guaranteed the problem would return. It's
back to the original "no route to host" symptoms, so maybe I solved ONE
problem, just not ALL problems. That's my way of looking at the bright
side...
This time I happened to be listening to musi
Interesting solution to a very similar (perhaps the same) problem:
http://www.opensubscriber.com/message/[EMAIL PROTECTED]/6477489.html
Put a CD in the CD drive--that'll stop the periodic timeouts.
Interesting.
--
CatBus
---
28 matches
Mail list logo
