I have been using Unraid for over two years now and thus far it has worked perfectly!! However in the last month or so I have been experiencing lockups (cannot access Shares from Network, cannot access Wed admin page, cannot open a shell on Unraid Server). My system is running headless, so I have been unable to access it directly. I know I can drag a monitor and keyboard out, but every time that it has happened I did not have the time. Now strangely enough it seems to always happen late Monday night to early Tuesday mornings. I thought this might be related to some sort of periodic parity check (I thought you could configure that, but I can't seem to find the knob now). I am currently running 4.5.6. I think the problem started close to the time I upgraded to 4.5.3. When I go to the system, it is powered up.

 

The syslog appears to be flushed when you reboot. Do you need to pull the flash and copy the syslog before reboot to see what was going on? Or is there a backup folder somewhere? Any other suggestions on how to debug the problem?

 

Also, it goes into parity check every time I reboot from this failure. Does it always perform a parity check on reboot...it don't recall it always doing this.

 

Thanks,

B2

If the system isn't shutdown cleanly, then it will force a parity check upon reboot.  The syslog is dumped when you reboot as well, although you could run a job to save it off periodically.  The fact that the lockup appears to be occurring Monday night / Tues morning does sound like you have something kicking off at that time that is causing the issue.

 

If you telnet into the server and type crontab -l it should list all the jobs that are configured to run.  Paste the results here.

 

I don't believe UNRaid itself automatically runs any parity checks, however there are packages available (are you running UnMenu?) that can be installed to do so, with the default being on the 1st of the month.

I do run Unmenu, but I am not aware of anything that I have set to run weekly.  Here is my crontab output:

 

 

# If you don't want the output of a cron job mailed to you, you have to direct

# any output to /dev/null.  We'll do this here since these jobs should run

# properly on a newly installed system, but if they don't the average newbie

# might get quite perplexed about getting strange mail every 5 minutes. :^)

#

# Run the hourly, daily, weekly, and monthly cron jobs.

# Jobs that need different timing may be entered into the crontab as before,

# but most really don't need greater granularity than this.  If the exact

# times of the hourly, daily, weekly, and monthly cron jobs do not suit your

# needs, feel free to adjust them.

#

# Run hourly cron jobs at 47 minutes after the hour:

47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null

#

# Run daily cron jobs at 4:40 every day:

40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null

#

# Run weekly cron jobs at 4:30 on the first day of the week:

30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null

#

# Run monthly cron jobs at 4:20 on the first day of the month:

20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

#

# Generated mover schedule:

40 3 * * * /usr/local/sbin/mover 2>&1 | logger

 

nothing there but what is supplied by lime-tech in their distribution.

bburns, do you by chance have a backup or anything running on another machine in that time frame that writes to the UNRaid server?

Not that I am aware of

Maybe the problem is on the client PC?

 

By any chance is that other machine running a Windows OS? Typically late Monday night to early Tuesday morning is when MS rolls out patches and updates. If you haven't changed the default configuration items, the PC will auto-install the patches and updates and reboot if needed. I'm not saying that could cause unRAID to lock up, but it's almost to coincidental to be during the same time realm.

I don't think it is the client as I have many machines and OS'es. When it happens nobody can access the unraid server:( I can't even shell into it.

 

B2