Jump to content

Strange issues forced a non clean shutdown


Recommended Posts

Had some weird stuff occur this morning and was wondering if anyone else has ever experienced this..

 

I went to watch a video file on one of my shares and it was saying "Unable to play file" even though it could see it. I tried it on another machine and same thing. I then tried to bring up the unraid web interface and it was unresponsive. Went and stopped the array from unmenu and then unmenu died.

 

I was able to restart unmenu but then the syslog portion wasn't working. Tried to manually restart emhttp from console but it was still not working.

 

Tried to call the /sbin/powerdown script for a clean shutdown and it got to where it says "No active PIDs on array" and then simply said "Terminated" and wouldn't proceed. I tried this twice with the same result.

 

I manually checked that the user shares weren't listed so I tried just the "reboot" command to reboot the box since powerdown wasn't working. This also go to where it said No active PIDs in this runlevel but then hung as well and never actually rebooted. Looking at the process list didn't show anything abnormal either.

 

Eventually I was forced to go powercycle the machine and its running it's parity check now, but the standard unraid web interface is still not working. Chrome gives me the following error now where as before it would give me nothing before the reboot:

 

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.

 

Firefox just gives a white page. I've tried manually restarting it twice but it doesn't correct anything.

 

Anyone ever seen this?

Link to comment

I had this exact thing happen to me last night. I went through all the steps you did up to the "pulling the plug" step. After reboot, system is up and running, and parity check completed with no errors this morning. I am not at home at the moment, so I can not post syslogs, etc... All SMART tests at shutdown were OK, jus the machine would not powerdown.

 

I am able to access the server over the web as normal.

Link to comment

I had this exact thing happen to me last night. I went through all the steps you did up to the "pulling the plug" step. After reboot, system is up and running, and parity check completed with no errors this morning. I am not at home at the moment, so I can not post syslogs, etc... All SMART tests at shutdown were OK, jus the machine would not powerdown.

 

I am able to access the server over the web as normal.

If processes are being terminated, you basically ran out of memory.  all kinds of unusual things happen when processes that are idle the longest are killed attempting to free ram for new proceses.

 

Either you are writing to RAM and filling it, or running too many add-ons.

 

Joe L.

Link to comment

The only way I would have run out of memory would be some sort of memory leak. I'm not writing anything to memory and the machine has 4GB of RAM and I've never seen it use more than 1GB. It had been online for many months without a reboot however.

 

Unfortunately memory usage is one thing I didn't check before powercycling and my syslog only shows entries after the reboot.

 

If it happens again I'll know to check that. Thanks.

Link to comment

I did notice that when my parity check first started it was very slow and I found the following log entries:

 

Nov  5 07:18:45 orbit kernel: REISERFS (device md1): replayed 374 transactions in 329 seconds (Minor Issues)

Nov  5 07:18:46 orbit kernel: REISERFS (device md1): Using r5 hash to sort names (Routine)

Nov  5 07:19:32 orbit kernel: REISERFS (device md7): replayed 251 transactions in 376 seconds (Minor Issues)

Nov  5 07:19:32 orbit kernel: REISERFS (device md7): Using r5 hash to sort names (Routine)

Nov  5 07:19:42 orbit kernel: REISERFS (device md3): replayed 267 transactions in 386 seconds (Minor Issues)

Nov  5 07:19:42 orbit kernel: REISERFS (device md3): Using r5 hash to sort names (Routine)

Nov  5 07:19:50 orbit kernel: REISERFS (device md6): replayed 296 transactions in 394 seconds (Minor Issues)

Nov  5 07:19:50 orbit kernel: REISERFS (device md6): Using r5 hash to sort names (Routine)

Nov  5 07:19:50 orbit kernel: REISERFS (device md8): replayed 327 transactions in 394 seconds (Minor Issues)

Nov  5 07:19:50 orbit kernel: REISERFS (device md8): Using r5 hash to sort names (Routine)

 

I suspect this is just due to the unclean shutdown?

Link to comment

I had this exact thing happen to me last night. I went through all the steps you did up to the "pulling the plug" step. After reboot, system is up and running, and parity check completed with no errors this morning. I am not at home at the moment, so I can not post syslogs, etc... All SMART tests at shutdown were OK, jus the machine would not powerdown.

 

I am able to access the server over the web as normal.

If processes are being terminated, you basically ran out of memory.  all kinds of unusual things happen when processes that are idle the longest are killed attempting to free ram for new proceses.

 

Either you are writing to RAM and filling it, or running too many add-ons.

 

Joe L.

 

I do only have 2GB of memory, but never see memory issues before. The only real add-ons I am using is UnMenu, although I do have some of the add-on scripts/binaries, too like clean powerdown, and that ilk. I am not running torrent, couch potato, sabnzb, or other add-ons that might use a bunch of memory.

 

No swap files, RAM disks, that might be eating up ram, and a pretty stock UnRAID.

Link to comment

I was going to verify memory usage before my power cycle with sar but it doesn't appear to be in the OS. Is this included in any of the betas and if not any chance to get this very useful tool included?

you can use

free

top

or

htop   (if you installed it)

as you said, sar is not included, and I don't know if system-accounting is enabled in the kernel... I never looked.

Link to comment

So my parity check completed without any sync issues but my main unraid web server is still not working even after another clean reboot. netstat shows port 80 listening with the emhttp service but the service sends me no data as it did before.

 

Any ideas?

 

Syslog doesn't show any errors or anything when it starts emhttp from what I can tell.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...