I have noticed several times already that the unraid webpage become permanently unavailable, al ot of times I have seen that this correspoinds with the user0 folder dissapearing (making the mover unable to run).

 

I have now seen the behaviour consistently a few times and I think I know when it happens. It has happened 3 times in a row now when I am moving large amounts of files thru telnet (mc) and/or thru console.

 

This is something I do more often when it is a big transfer so it is very possible that this has been the same before also.

 

My server is currently in this "webpage unavailable" state.

 

All shares still available. I am running v6b9, but this has happened in a lot of releases, back to V5. I am running no plugins but have cache_dirs enabled.

 

ps -elf on emhttp:

 

4 S root      1531     1  0  80   0 - 39161 sk_wai 07:14 ?        00:00:04 /usr/local/sbin/emhttp

 

Attached my syslog

 

I did notice that cache_dirs was no longer running.. I restarted it.

syslog.zip

I have noticed several times already that the unraid webpage become permanently unavailable, al ot of times I have seen that this correspoinds with the user0 folder dissapearing (making the mover unable to run).

Do you meant the /mnt/user0 folder is entirely gone, or that it's "there" but there are a lot of "?" marks shown for it's entry?

 

I have now seen the behaviour consistently a few times and I think I know when it happens. It has happened 3 times in a row now when I am moving large amounts of files thru telnet (mc) and/or thru console.

Please give me an example of the exact commands you use.

 

This is something I do more often when it is a big transfer so it is very possible that this has been the same before also.

 

My server is currently in this "webpage unavailable" state.

 

All shares still available. I am running v6b9, but this has happened in a lot of releases, back to V5. I am running no plugins but have cache_dirs enabled.

 

ps -elf on emhttp:

 

4 S root      1531     1  0  80   0 - 39161 sk_wai 07:14 ?        00:00:04 /usr/local/sbin/emhttp

 

Attached my syslog

The 'sk_wai' means 'sk_waitd_data' - this is the function where a process typically waits for a packet from a tcp/ip socket.  Not sure why it should be hanging there...

 

I did notice that cache_dirs was no longer running.. I restarted it.

How did you determine that?

 

If you try your transfers without cache_dirs running, same result?

Thanks for the reply.

 

The moments user0 is gone (which is not every time the webpage becomes unresponsive, but often) the user0 is totally gone when I check in /mnt using telnet. 

 

What i do is either telnet into the system, use ipmi or even just use the physical keyboard and monitor on the machine. Then start MC. Set left to /mnt/disk5/movies and /mnt/disk2/movies to the right, select a bunch of folders, typically something that will keep it busy for more then 10 hours. Then press Renmove, no other options.

 

I did a ps -elf | grep cache_dirs and got nothing back, restarted it using the same command as in the go file.

 

I have not tried without cache dirs because I find it a very important part of my personal setup, but I terminate the transfer and restart without cache_dirs lateron.

 

Any more you want me to test with the current system while it is in this state ?

 

 

 

 

 

Just remembered... The syslog waa from the time this happened yesterday.. The cachedirs not running was from the last time it happened.

 

I will get the syslog from this moment lateron together with a process list.

Is your sig accurate, that you're running unRaid in an ESXI VM?  (and what is "Unraid 6.02b"?)

Stoneold sig... I'll change it right away...

 

Herewith the current syslog and ps, just grabbed it a second ago.

 

 

ps.zip

syslog.zip

My web page are also unavailable right now.. Can't get a syslog right now. I have this issue an several version back

 

Last night I changing FS on one drive, started the array and copy files to the new drive GUI was ok then, this morning the GUI is dead.

 

Last lines in my syslog..

 

 

 

Sep 13 22:45:38 Tower avahi-daemon[17306]: Service group file /etc/avahi/services/afp.service changed, reloading.

Sep 13 22:45:38 Tower emhttp: shcmd (424): /usr/local/sbin/emhttp_event svcs_restarted (Other emhttp)

Sep 13 22:45:38 Tower emhttp_event: svcs_restarted (Other emhttp)

Sep 13 22:45:39 Tower avahi-daemon[17306]: Service "Tower" (/etc/avahi/services/smb.service) successfully established.

Sep 13 22:45:39 Tower avahi-daemon[17306]: Service "Tower-AFP" (/etc/avahi/services/afp.service) successfully established.

Sep 13 23:13:07 Tower kernel: mdcmd (42): spindown 9 (Routine)

Sep 13 23:15:47 Tower emhttp: shcmd (425): /usr/sbin/hdparm -y /dev/sdg $stuff$> /dev/null (Drive related)

Sep 14 04:11:00 Tower emhttp: shcmd (426): /usr/sbin/hdparm -y /dev/sdg $stuff$> /dev/null (Drive related)

Sep 14 04:12:41 Tower kernel: mdcmd (43): spindown 9 (Routine)

Sep 14 04:40:01 Tower crond[19515]: unable to exec /usr/sbin/sendmail: cron output for user root /usr/bin/run-parts /etc/cron.daily 1> /dev/null to /dev/null

Sep 14 07:08:22 Tower in.telnetd[32257]: connect from 192.168.0.179 (192.168.0.179) (Routine)

Sep 14 07:08:34 Tower login[32258]: ROOT LOGIN  on '/dev/pts/2' from 'Peters-iPhone' (Logins)

My web page are also unavailable right now.. Can't get a syslog right now. I have this issue an several version back

 

Can you get at console or telnet?  If so what does this output say?

 

ps -elf | grep emhttp

Here it is

 

 ps -elf | grep emhttp
0 S root      6633  6618  0  80   0 -  1274 pipe_w 08:19 pts/2    00:00:00 grep emhttp
4 S root      6970     1  0  80   0 - 39186 sk_wai Sep13 ?        00:00:15 /usr/local/sbin/emhttp

Here it is

 

 ps -elf | grep emhttp
0 S root      6633  6618  0  80   0 -  1274 pipe_w 08:19 pts/2    00:00:00 grep emhttp
4 S root      6970     1  0  80   0 - 39186 sk_wai Sep13 ?        00:00:15 /usr/local/sbin/emhttp

 

Are you also running cache_dirs ?

 

Same error message I get...

Are you also running cache_dirs ?

 

Same error message I get...

No cache_dirs

I just stopped the running transfers on the console and rebooted. I have checked and cache_dirs again does not seem to be running. It is in my GO file.. I have not yet started any transfers so the system is in a just rebooted state. Attached see syslog and ps of that just rebooted state.

 

I have also included my GO file, just in case the fact that cache_dirs does not start has anything to do with it.

 

After this post I will restart the transfers, I will be gone for the day and will post status at the moment I am back.

ps_new.zip

syslog_new.zip

go.zip

Just started the transfers. Webpage still available, this is allways the case, unavailability occurs only after a longer time of performing actions on the array.

Which browser are you guys using?  Does it make a difference if you use a different browser?

 

Here's a way to get more info.  In the 'go' file modify this line:

 

/usr/local/sbin/emhttp &

 

to

 

/usr/local/sbin/emhttp -d2 &

 

And then reboot.

 

This will cause emhttp to log all the http requests - this will quickly fill up your syslog though if you use webGui a lot.

I'm using Chrome ,I have rebooted with above settings, and started to update FS on next drive.

 

//Peter

I use chrome, but emhttp does not crash by chrome.. I really think there is a combination with a lot of file transfer..

 

I will make the new setting when I am back home.

@Tom, My GUI stopped again, I PM you a link to my syslog, where I have enabled -d2

 

//Peter

@Tom, My GUI stopped again, I PM you a link to my syslog, where I have enabled -d2

 

//Peter

 

That's a helluva system log...  There is a lot going on in there and will take me more time to analyze.  Here are a few things:

a) looks like your disk6 has big problems

b) you are invoking s3_sleep?  What plugin is doing this?

c) I know everyone likes that powerdown script, but it's not supported and we will be doing this a different way

 

Is there any way you can simplify things?  For example, run without plugins, do let server sleep, etc?  There does not appear to be a "magic bullet" syslog entry that explains this.

I'm rebuilding disk 6 right now, don't know why I got a red ball on that today? All my drives are xfs now.

I'm rebuilding disk 6 right now, don't know why I got a red ball on that today? All my drives are xfs now.

syslog shows physical read errors.  Might want to check all your cabling, take a look at the smart log.

My system has been stable as hell... The parameter for emhttp is in but the gui is still responsive... I am throwing some extra drive copies on there to see if I can get it to fail.. But I guess it is not as reproducable as I thought..

My system has been stable as hell... The parameter for emhttp is in but the gui is still responsive... I am throwing some extra drive copies on there to see if I can get it to fail.. But I guess it is not as reproducable as I thought..

 

Keep us posted.  I can tell you that almost every instance in which I've seen a webgui hang, it's not unRAID, but a plugin that is causing it.  I actually haven't had a webGui hang for me in over 6 months now on 4 different test systems.  Keep in mind, I BEAT on these things daily with MASSIVE file transfers both locally and over the network.  That said, I do not have any plugins of any kind installed.

Still stable.. I never run plugins though, with the exception of cachedirs. I see that as a necessity.

good to hear.  i will mark this thread as solved for now.  if the issue comes back, let us know.

Still stable here as well :-)