Hi,

 

Is there a way to verify what packages/features scripts are running in the background? It seems that I am getting parity check on a weekly basis but cannot remember if I set anything. I check my GO script and found this only:

 

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &

/boot/unmenu/uu

 

Is there anywhere else things are being loaded or set? Thanks!

 

It's possible you have something entered in cron that is being run but is not set to reinstall on boot.  To see a list of what is scheduled log into the console and execute

crontab -l

Lines that start with # are comments and ignored by the scheduler.

The format is

minutes hours day-of-month month day-of-week command-to-execute

 

Look for something similar to

/root/mdcmd check NOCORRECT 1>/dev/null 2>&1

for a parity check.  That is what I use and have it set to go monthly.  Of course the actual command to issue the check could be embedded in another script, but take a look and see if something jumps out.

 

If you have any questions about the output, you can issue

crontab -l | todos >> /boot/crontab.txt

and attach the file here.

It's possible you have something entered in cron that is being run but is not set to reinstall on boot.  To see a list of what is scheduled log into the console and execute

crontab -l

Lines that start with # are comments and ignored by the scheduler.

The format is

minutes hours day-of-month month day-of-week command-to-execute

 

Look for something similar to

/root/mdcmd check NOCORRECT 1>/dev/null 2>&1

for a parity check.  That is what I use and have it set to go monthly.  Of course the actual command to issue the check could be embedded in another script, but take a look and see if something jumps out.

 

If you have any questions about the output, you can issue

crontab -l | todos >> /boot/crontab.txt

and attach the file here.

 

 

 

Here is the output:

Linux 2.6.32.9-unRAID.

root@Tower1:~# crontab -l

# 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

 

 

I am not seeing any parity check. Thanks!

Me neither, that looks like the default crontab.  Not sure what else could be calling a weekly parity check.  I'm not sure where unRAID stores the info for the last parity check, but it hoards it somewhere because it persists across reboots.  If anyone knows, please chime in; I'm curious

 

As long as you haven't rebooted, you can look in the syslog to verify that it has run but you won't see what called it.  At least you can get an idea of the start times and that may help you narrow down the starting process.

grep parity /var/log/syslog

will show you when the parity syncs started and

grep "md: sync done" /var/log/syslog

will show you when they finished and the stats.

Since I am paying more attention to the higher frequency of my parity check, I have noticed the following:

-One server was frozen and had a hard reset. Parity kicked in after server started.

-The other server was shut down using "poweroff" command from the console and started a parity check immediately at startup.

 

I was talking to my colleague about this and he said that parity will kick in to resync after a hard reset (unraid built in feature). Also, shutting down the server using "Poweroff" command is not the right way and may trigger a parity check also. Can someone confirm? Thanks.

Yes and Yes, both will start a parity check on re-start.

 

Your weekly checks are likely the result of someone not shutting the server down cleanly.

 

Peter

Thanks! Besides webgui shutdown, what is the proper way to shut down the server (clean) from the console? Powerdown?

I will avoid "Poweroff".

Thanks! Besides webgui shutdown, what is the proper way to shut down the server (clean) from the console? Powerdown?

I will avoid "Poweroff".

 

If there is anything running on the server and holding it busy (could even be a telnet connection) then the server will not shut down.

 

Install the powerdown package the comes with unMenu and you can use it to powerdown cleanly.  Just type powerdown on the console, hit the power button on the computer, or press control-alt-delete.

...hit the power button on the computer...

 

Do you mean just a single quick press?

 

 

...hit the power button on the computer...

 

Do you mean just a single quick press?

 

 

 

Yes, once the powerdown package is installed a quick press should be enough to kick of the powerdown.  It may take a while but it should eventually work.

 

NOTE: I think there is a limitation in that your motherboard has to support APCI or ACPI correctly.

I upgraded to Unraid 4.6 and unMenu 1.3 178. I installed Powerdown package from unMenu.

Using Telnet, I ran "Powerdown" and after about 20sec, it completely shutdown. I power up the server again and parity check is not running. So, the shut down was clean.

 

I do not have to press the power button or Alt-Ctr-Del.

 

Thanks!

I do not have to press the power button or Alt-Ctr-Del.

 

No, you do not have to.  I believe that you can install the powerdown package so that control-alt-delete can be used instead of typing powerdown at the command line.  I do not always have a monitor hooked up to my production server, but I do have a keyboard hooked up.  That makes it easy to hit the three button combo and shut down the server.