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 SlimServer breaks for four > hours in the middle of the night, do I care?
But it wouldn't fix anything... Since "something" other than uptime is the cause here, the only thing a reboot would cure would be that during that reboot, "something" could not happen. That wouldn't stop it from occuring at any other time, though. > > I'll check inodes, but considering this server is basically vanilla OS > + SSH + SlimServer, I'm thinking that's not it. I'll also check free > space more regularly just to see if there's sudden spikes in disk usage > for any reason. On Debian, the log file by default ends up in /var/log/slimserver/slimserver.log. Is that where yours is? Is /var/log a different partition than /tmp? If it is, you may want to try this: mkdir /var/log/slimserver chown slimserver /var/log/slimserver and edit the /etc/init.d/slimserver so that it uses /var/log/slimserver/slimserver.log The other thing I would look at is making sure you didn't "help" convert.conf and changes stuff there: it is pretty easy to change things so that decoding goes to a file instead of a pipe. (Unlike old DOS programs that made strange temp files for pipes, Unix doesn't use any file space at all for pipes: when the pipe-reader stops accepting input, the pipe-writer is suspended until there is room to buffer more data to the reader... or if the writer stops writing, the reader is suspended until it has input to read.) It may also be that some stream of errors in a given file is spewing tons of data in a log... for example, a AAC file transcoded to FLAC, but the AAC is massively corrupted, so MOV123 spits out lots and lots of "I don't know what this frame is, nor this one, nor this one". Ah, yes, and with some versions of MySQL, joins and unions can make temporary files in /tmp. (I saw this a loong time ago with SQLPlaylist... MySQL tried to optimize a query and would expand a query into literally millions of queries and leave a huge file in /tmp.) That shouldn't be a problem with MySql5, but it was ugly there for a while. -- snarlydwarf ------------------------------------------------------------------------ snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179 View this thread: http://forums.slimdevices.com/showthread.php?t=34229 _______________________________________________ unix mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/unix
