I'm getting confused & want to start again....

[Suse User]

With all the user tips & hack, combined with the numerous configuration variations I'm getting confused about what I've already done & what I need to do to have my unraid server performing at it's best.

 

My current go script is:-

 

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &
echo "nameserver 158.152.1.58" >/etc/resolv.conf
sleep 30
for i in /dev/md*
do
    blockdev --setra 2048 $i
done
cp /boot/smtp_check_unraid.sh /etc/cron.hourly/
/boot/spin_drives.sh &
sleep 90
ethtool -s eth0 wol g
#installpkg /boot/packages/powerdown-1.02.tgz

 

I no longer recall what some of these lines do, or whether they are still necessary.

 

I've been reading the Keep directory entries cached wiki post and the Cache Dirs thread and wish to add:-

 

/boot/cache_dirs -w -e "backup" to my go script and include the latest version of the relevant cache_dirs script to my USB key.

 

Are there items in my go script that are obsolete? or perhaps missing for improving performance?

 

I'm running 4.5beta1 as when I tried beta 6 my passwords were ignored and everything was available to everyone on the network.

 

I'm about to try beta7 and I'd like to give it the best chance of working well for me.

 

Even better would be if someone could post a go script that uses the directory caching & file buffering scripts to give optimum performance.

 

On a side note, I currently have 2GB ram, but I've another 2GB of the same RAM spare from another machine, would 4GB be overkill?

 

Thanks for any guidance,

 

Mark.

 

 

[purko]

Are there items in my go script that are obsolete?

I would say yes. Cut the whole thing down to:

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp 

 

a) You don't need to set the nameserver here; You do in the unRAID Management web page.

b) My experience is that unRAID's stock 1024 readahead for the "md" devices is optimal.

 

 

[Joe L.]

You might want to leave the last few lines... and fix the very last one, as it is commented out.

(lines with a leading "#" are comments.  You might even add a few to remind yourself why you made the changes.)

 

# Schedule a check of the array status every hour.  Mail a notification if failure occurs.

cp /boot/smtp_check_unraid.sh /etc/cron.hourly/

 

# Not sure what spin_drives.sh does...  It might spin up drives when media player is detected??

/boot/spin_drives.sh &

 

# delay 1 1/2 minutes.

sleep 90

 

# set wake-on-lan state

ethtool -s eth0 wol g

 

# This installpkg line would be used to install the powerdown script.  I would un-comment it (remove the leading "#")

# as it is really handy to have to cleanly stop your array..

#installpkg /boot/packages/powerdown-1.02.tgz

[purko]

# This installpkg line would be used to install the powerdown script.  I would un-comment it (remove the leading "#")

# as it is really handy to have to cleanly stop your array..

 

I was under the impression that the latest unraid builds provide for a clean powerdown.

On examining my stock unraid box I see:

root@Tower:~#
root@Tower:~# which powerdown
/usr/local/sbin/powerdown
root@Tower:~# cat  /usr/local/sbin/powerdown
#!/bin/bash
#
# Helper script to gracefully power-down unRAID server.
# Works only if webGui is running and listening on port 80.

# Access a blank page in case this is first request since startup.
/usr/bin/wget -q -O - localhost/blank.htm >/dev/null

# Have emhttp do all the work as if user clicked 'shutdown' in webGui.
/usr/bin/wget -q -O - localhost/update.htm?shutdown=apply >/dev/null
root@Tower:~#

 

Am I wrong in thinking that the above is all that's needed for a clean powerdown?

I mean, clicking on the ShutDown button in the unRAID main interface, isn't that clean?

 

Purko

 

 

 

[Joe L.]

# This installpkg line would be used to install the powerdown script.  I would un-comment it (remove the leading "#")

# as it is really handy to have to cleanly stop your array..

 

I was under the impression that the latest unraid builds provide for a clean powerdown.

On examining my stock unraid box I see:

root@Tower:~#
root@Tower:~# which powerdown
/usr/local/sbin/powerdown
root@Tower:~# cat  /usr/local/sbin/powerdown
#!/bin/bash
#
# Helper script to gracefully power-down unRAID server.
# Works only if webGui is running and listening on port 80.

# Access a blank page in case this is first request since startup.
/usr/bin/wget -q -O - localhost/blank.htm >/dev/null

# Have emhttp do all the work as if user clicked 'shutdown' in webGui.
/usr/bin/wget -q -O - localhost/update.htm?shutdown=apply >/dev/null
root@Tower:~#

 

Am I wrong in thinking that the above is all that's needed for a clean powerdown?

I mean, clicking on the ShutDown button in the unRAID main interface, isn't that clean?

 

Purko

 

 

 

The "shutdown" command that Tom added is just a call to the web-interface using "wget".  If the normal web-interface is un-responsive, it will not do anything to shut you down.   Since most of the time when we want to shut down via the command line it is because the web-interface is not available, I consider his solution to be less useful then it might appear.

 

His own comments in his "powerdown" script say it will only work if the management console is working and responsive

#!/bin/bash

#

# Helper script to gracefully power-down unRAID server.

# Works only if webGui is running and listening on port 80.

 

# Access a blank page in case this is first request since startup.

/usr/bin/wget -q -O - localhost/blank.htm >/dev/null

 

# Have emhttp do all the work as if user clicked 'shutdown' in webGui.

/usr/bin/wget -q -O - localhost/update.htm?shutdown=apply >/dev/null

 

With the most recent changes to emhttp, it will sit forever and NOT shut down if a disk is busy. (You've cd'd to a directory on a disk and it is your current directory, or the directory you started a process in)  It will wait  patiently...forever...

 

With all that in mind, the original "powerdown" script is still very useful.  If the management interface fails, it might be the only way to shut down cleanly.   I know it will terminate processes keeping disks busy, so it will not wait forever for an action that might not ever occur.   

 

I'm a bit sorry Tom used the same command name for his "powerdown" script... he was probably trying to avoid confusion.   It is OK, we'll adapt... but to protect yourself, you might want to keep installing the powerdown-1.02.tgz package.  You may never need it, but... if you do, you'll be happy you did.

 

I know the original powerdown installs itself in /sbin/powerdown.  The APC UPS control script expects it to be there.   Tom's version installs itself in /usr/local/sbin/powerdown.   They will not conflict with each other.

 

Joe L.

[purko]

Thanks Joe for this clarification.

[Suse User]

I appreciate the help here...

 

I've now changed my go script to the following:-

 

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

#Increased read buffer (I think) Remarked out as unnecessary
#sleep 30
#for i in /dev/md*
#do
#    blockdev --setra 2048 $i
#    blockdev --getra $i
#done

# Schedule array status check & email if failure
cp /boot/smtp_check_unraid.sh /etc/cron.hourly/

# Spin up drives if media player detected
# /boot/spin_drives.sh &

#Delay 90 seconds Remarked out as unnecessary
#sleep 90

# Set wake-on-lan state
ethtool -s eth0 wol g

# Install Clean powerdown script
installpkg /boot/packages/powerdown-1.02.tgz

# Cache directory lists 
/boot/cache_dirs -w -e "backup"

 

I've commented out the blockdev section as it didn't seem to feature in Purko or Joe's suggestions, I'll delete completely when I'm sure it adds nothing.

 

The spin_drives.sh was used to spin up all drives when the IP address of the media player was detected, I seem to remember this was to stop directory listings on my media player timing out due to the time taken for the drives to spin up.  I'm hoping that the cache_dirs script will now provide that solution.

 

I don't recall why I was waiting 90 seconds so I'm guessing that can also be removed?

 

Thanks again,

 

Mark.