Automating tasks: rsync works!

I think everything is running fairly smoothly - just have 1 more drive to RMA.   The next step is putting in some automated tasks.  Here's what I want to do.

I have 2 unRAID servers.  Server1 and Server2

Both servers currently have 4 disks - parity and 3 data (for now), and I want the content on the two servers to mirror each other (I assume they'll both have slightly different parity drives though depending on sector copy order, etc.)

I want to program in some basic maintenance tasks as well.  Right now, I am concentrating on:

1) Setting up a bimonthly parity check to run at 3 am on the 1st and 14th of each month

2) Setting up a short SMART test to run at 3 am on all drives on the 7th of each month

3) Setting up a long SMART test to run at 3 am on all drives on the 21st of each month

4) Setting an rsync script to copy all new data between the two computers (drive to drive) at 3 am each day it is not running maintainance - Server1 should copy via rsync to Server2

(note: 3 am is arbitrary, but seems sufficiently late that I doubt it'll be out of the way much when I need it.

The forums have been wonderful, and all of this is covered, with a little digging, to some degree or another.  After a couple days of forum browsing, I think I know what I have to do, but wanted to place my scripts and whatnot below in case I'm missing something or put in something that will make the server explode    (and of course, as a place I can get help from if any problems arise)

First, the questions.  is there any way I can 'loop' the drives so that I don't have to add additional lines whenever I add a new drive?  (If you notice, right now I repeated everything for each drive)

Will the SMART tests (and the rsync copies, for that matter) for each drive be executed simultaneously?  If not, how can I set this up?  This is especially important for the long SMART tests.

Will the same letters (sda sdb, etc.) always be assigned to the same drives?  Right now, my usb drives are on sdc in both computers, but if that starts jumping around, the scripts below will likely develop issues (some disks will be left out, or the computer will try and do who-knows-what to the USB drive)  If this isn't guaranteed, how can I modify the code below so it's not an issue?

The first thing I think I need to do is add the following lines to the end of my go script:

crontab -l >/tmp/crontab

# parity checks on the 1st and 14th at 3am
# user notice of check
echo "# check parity on the 1st and 14th of every month at 3am:" >>/tmp/crontab
# check command
echo "0 3 1,14 * * /root/mdcmd check 1>/dev/null 2>&1" >>/tmp/crontab

#run short smart test on the 7th
echo "# short smart test on the 7th every month at 3am:" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sda" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sdb" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sdd" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sde" >>/tmp/crontab

#run long smart test on the 21st
echo "# long smart test on the 21st every month at 3am:" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sda" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sdb" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sdd" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sde" >>/tmp/crontab

#set up rsync between the two servers every other day at 3 am - will be commented out for Server2 go script
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk1/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk2/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk3/*" >>/tmp/crontab

crontab /tmp/crontab

Next, I need to create a file called rsyncd.conf in the flash drive under /boot/bubba/boot/rsyncd.conf (where I've stored unmenu too)- and another copy in /etc/rsyncd.conf (copied into the filesystem via putty/samba/whatever)  These files only need to be created in Server1 (right?)

File contents:

uid             = root
gid             = root
use chroot      = no
max connections = 4
pid file        = /var/run/rsyncd.pid
timeout         = 600

[disk1]
    path = /mnt/disk1
    comment = Disk 1
    read only = FALSE

[disk2]
    path = /mnt/disk2
    comment = Disk 2
    read only = FALSE

[disk3]
    path = /mnt/disk3
    comment = Disk 3
    read only = FALSE

Is this all I have to do?  Also, if I add a password to the two servers for better security, how would I have to modify the rsync scripts?

I assume I would just add the following lines in rsync.conf after timeout = 600:

auth users = myusername
hosts allow = server1ipaddress server2ipaddress
secrets file = /etc/rsyncd.scrt (or wherever I put it)

and then make a rsyncd.scrt file with the lines:

username:password

Looking back over all of this, I think I'm missing something in the rsync script - I don't see any way for it to know where on Server2 to copy the files to...(disk1 sould go to disk1, etc)

Does each server need a separate rsyncd.conf file?  If so, how should they differ?

What else is wrong with what I've come up with so far?  Any suggestions/improvements?  (If anyone has something that pretty much does exactly what I want, feel free to post it too, but you'll probably have to guide me through how to modify it for my own use

Thanks in advance, and I apologize if I missed something obvious (I read the forums and tried to do as much of this on my own as I could, but I'm bound to have missed a thing or two)

Zithras

The lines in the crontab you defined to run smart tests are incorrect.  They should not have /root/mdcmd in them at all.

They should look like this:

#run short smart test on the 7th

echo "# short smart test on the 7th every month at 3am:" >>/tmp/crontab

echo "0 3 7 * *  smartctl -d ata -tshort /dev/sda" >>/tmp/crontab

echo "0 3 7 * *  smartctl -d ata -tshort /dev/sdb" >>/tmp/crontab

echo "0 3 7 * *  smartctl -d ata -tshort /dev/sdd" >>/tmp/crontab

echo "0 3 7 * *  smartctl -d ata -tshort /dev/sde" >>/tmp/crontab

#run long smart test on the 21st

echo "# long smart test on the 21st every month at 3am:" >>/tmp/crontab

echo "0 3 21 * *  smartctl -d ata -tlong /dev/sda" >>/tmp/crontab

echo "0 3 21 * *  smartctl -d ata -tlong /dev/sdb" >>/tmp/crontab

echo "0 3 21 * *  smartctl -d ata -tlong /dev/sdd" >>/tmp/crontab

echo "0 3 21 * *  smartctl -d ata -tlong /dev/sde" >>/tmp/crontab

I think everything is running fairly smoothly - just have 1 more drive to RMA.   The next step is putting in some automated tasks.  Here's what I want to do.

 

I have 2 unRAID servers.  Server1 and Server2

 

Both servers currently have 4 disks - parity and 3 data (for now), and I want the content on the two servers to mirror each other (I assume they'll both have slightly different parity drives though depending on sector copy order, etc.)

 

I want to program in some basic maintenance tasks as well.  Right now, I am concentrating on:

 

1) Setting up a bimonthly parity check to run at 3 am on the 1st and 14th of each month

2) Setting up a short SMART test to run at 3 am on all drives on the 7th of each month

3) Setting up a long SMART test to run at 3 am on all drives on the 21st of each month

4) Setting an rsync script to copy all new data between the two computers (drive to drive) at 3 am each day it is not running maintainance - Server1 should copy via rsync to Server2

(note: 3 am is arbitrary, but seems sufficiently late that I doubt it'll be out of the way much when I need it.

 

The forums have been wonderful, and all of this is covered, with a little digging, to some degree or another.  After a couple days of forum browsing, I think I know what I have to do, but wanted to place my scripts and whatnot below in case I'm missing something or put in something that will make the server explode    (and of course, as a place I can get help from if any problems arise)

 

First, the questions.  is there any way I can 'loop' the drives so that I don't have to add additional lines whenever I add a new drive?  (If you notice, right now I repeated everything for each drive)

Will the SMART tests (and the rsync copies, for that matter) for each drive be executed simultaneously?  If not, how can I set this up?  This is especially important for the long SMART tests.

Will the same letters (sda sdb, etc.) always be assigned to the same drives?  Right now, my usb drives are on sdc in both computers, but if that starts jumping around, the scripts below will likely develop issues (some disks will be left out, or the computer will try and do who-knows-what to the USB drive)  If this isn't guaranteed, how can I modify the code below so it's not an issue?

 

The first thing I think I need to do is add the following lines to the end of my go script:

 

crontab -l >/tmp/crontab

# parity checks on the 1st and 14th at 3am
# user notice of check
echo "# check parity on the 1st and 14th of every month at 3am:" >>/tmp/crontab
# check command
echo "0 3 1,14 * * /root/mdcmd check 1>/dev/null 2>&1" >>/tmp/crontab

#run short smart test on the 7th
echo "# short smart test on the 7th every month at 3am:" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sda" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sdb" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sdd" >>/tmp/crontab
echo "0 3 7 * * /root/mdcmd smartctl -d ata -tshort /dev/sde" >>/tmp/crontab

#run long smart test on the 21st
echo "# long smart test on the 21st every month at 3am:" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sda" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sdb" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sdd" >>/tmp/crontab
echo "0 3 21 * * /root/mdcmd smartctl -d ata -tlong /dev/sde" >>/tmp/crontab

#set up rsync between the two servers every other day at 3 am - will be commented out for Server2 go script
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk1/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk2/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk3/*" >>/tmp/crontab

crontab /tmp/crontab

 

Next, I need to create a file called rsyncd.conf in the flash drive under /boot/bubba/boot/rsyncd.conf (where I've stored unmenu too)- and another copy in /etc/rsyncd.conf (copied into the filesystem via putty/samba/whatever)  These files only need to be created in Server1 (right?)

File contents:

uid             = root
gid             = root
use chroot      = no
max connections = 4
pid file        = /var/run/rsyncd.pid
timeout         = 600

[disk1]
    path = /mnt/disk1
    comment = Disk 1
    read only = FALSE

[disk2]
    path = /mnt/disk2
    comment = Disk 2
    read only = FALSE

[disk3]
    path = /mnt/disk3
    comment = Disk 3
    read only = FALSE

 

Is this all I have to do?  Also, if I add a password to the two servers for better security, how would I have to modify the rsync scripts?

I assume I would just add the following lines in rsync.conf after timeout = 600:

auth users = myusername
hosts allow = server1ipaddress server2ipaddress
secrets file = /etc/rsyncd.scrt (or wherever I put it)

 

and then make a rsyncd.scrt file with the lines:

username:password

 

Looking back over all of this, I think I'm missing something in the rsync script - I don't see any way for it to know where on Server2 to copy the files to...(disk1 sould go to disk1, etc)

Does each server need a separate rsyncd.conf file?  If so, how should they differ?

 

What else is wrong with what I've come up with so far?  Any suggestions/improvements?  (If anyone has something that pretty much does exactly what I want, feel free to post it too, but you'll probably have to guide me through how to modify it for my own use

 

Thanks in advance, and I apologize if I missed something obvious (I read the forums and tried to do as much of this on my own as I could, but I'm bound to have missed a thing or two)

Zithras

 

Please read up on the Third Party Boot Architecture.  The regular members on the board are using it or some form of it, and it is the preferred setup.  Please also read up on this thread and see the .zip file that is attached to the second post (WeeboTech's).

My go script looks a lot like his (a little differnet since I am running BubbaRaid) but i have this in my go script:

#!/bin/bash
# Start the Management Utility
# Modified by BubbaRaid
#

# set unraidport to the port for emhttp to use for a standard unRAID boot
# set bubbaraidport to the port for emhttp to use for a BubbaRaid boot

unraidport=80
bubbaraidport=88

# Test the uname to see if BubbaRaid was booted
uname -r | egrep "(Bubba)|(bubba)" >/dev/null 2>&1
if [ ! $? = 0 ]
  then
    port=$unraidport
  else
    port=$bubbaraidport
fi

echo "Starting unRAID Management Utility on port" $port
/usr/local/sbin/emhttp -p $port &

# Get those scripts run through fromdos for posterities sake
fromdos < /boot/custom/etc/rc.d/rc.local_startup | sh

# Start up unmenu
/boot/unmenu/uu

From there i have some scripts in my folders that match the Third Party Boot Architecture.  I have one called S01-blockdev, S10-install_customer_packages, S80-update_hosts, and weekly_parity_check.sh (<-- my parity check script).

If you need any more information feel free to ask!!

I'll preface my remarks with the comment that I do understand we are all different, and that that is OK, completely normal.  Some folks like to worry about everything, heavily insure themselves against every possible risk, plan every detail of every task, and still constantly worry.  Others don't worry or plan for the future at all, or any problems until they occur, sometimes until too late.  Most people are somewhere on the spectrum between those 2 extremes.  I suspect that you are closer to the first than the second, so I thought I would mention a couple of thoughts for consideration.

It's my *opinion* (not well supported by sufficient scientific studies) that in some cases, too much intensive measurement can affect the measurement itself.  If drives are spun down most of the time, and if the tests of their status comprise a substantial proportion of their usage, then the testing of wear and tear becomes a prime cause *of* the wear and tear.  It becomes a variation of what is often called the 'Heisenberg Uncertainty principle', where the observer affects the observed.  (Actually it is a misinterpretation of the Uncertainty principle, better called the Observer effect or Heisenbug.)  We don't want to wear out a drive prematurely by over testing it.  I am not an expert here, so I may be wrong about this, and it is possible that deep surface testing does not affect the long term life of the drive at all.  I welcome more expert comments on this.

My drives mostly stay spun down.  I cannot see the point in spinning up a drive just to test it, except on a very sparse schedule.  I personally prefer parity checks and SMART short tests on a quarterly schedule (or when needed of course), and perhaps yearly or longer for a SMART long test.  I do understand that others prefer much more often, and I have no good data to offer one way or the other.  More often feels right to them, less often feels right to me.  I will fully respect what ever decisions you and others make.

I'll just add one more comment.  There have been a rash of hard drive issues lately, and a number of other support issues that revealed at times that a recent parity check would have avoided some of the problems.  But I don't want users to over-react to these, become too paranoid.  I *think* that the problems are statistically anomalous, just a blip.  If reasonable monitoring AND backup strategies are implemented, I don't see a reason to go overboard in over-testing.  Of course, the effect of all of the problems can be good, if it leads at least one more person to establish better backup planning AND implementation!

In my opinion, the "parity" checks perform exactly the same inspection of all the disk blocks as the "long" smart self-test.  The "long" test adds no value at all.  In the same way, the "short" test tells you absolutely nothing you do not already know from the server, especially if you are doing by-weekly parity checks.

What I would do is install the "Smart-Reports" package that BubbaQ developed and have it run its "smart status" report (daily, weekly?) so it can track errors as they develop in its smart database.  That will give you the most bang-for-your-buck.  To run all your tests is is meaningless unless you have a good way to compare and track the results.  The thread describing it is here: http://lime-technology.com/forum/index.php?topic=3146.0

I added a button to invoke it from my unMENU user-scripts page as described in this post:

http://lime-technology.com/forum/index.php?topic=3146.msg26999#msg26999

The exact same script could be run weekly from cron (throwing away the output) to ensure periodic smart tests are performed and logged.

Joe L.

I agree with everything that has been said here.  I agree with JoeL in that to much checking could itself cause problems.  I do not need my parity script to run weekly, in fact i will soon be reworking the script so that it runs only once a month.  The reason I have it running weekly is that i have been adding, moving around, and reorganizing a lot of drives in the last month or so and I wanted to make sure that something did not go wrong (or at least that my parity drive was good).

Nor really sure you have been running unRAID but if the server is fairly new then doing some of this stuff is probably not a bad idea.  Once the server is set up and running you can probably back off on a lot of these tests.  Make the parity checks once a month and also back of on the smart testing.

That's just my opinion so take it as you like

Actually, looking over it, I don't think that I really need to run smart tests on the drives as well as parity tests.  I'd still like the parity tests scheduled for twice a month (especially for the first few months), but I'll pass on the SMART tests unless someone suggests that they're actually necessary.  The original plan was to just run parity checks once or twice a month (and daily rsync, of course, so I won't have to manually copy data twice), but I was quite unclear from the forums whether long SMART tests offered benefits that parity checks didn't (since parity checks essentially tested every sector anyway), so I threw them in just in case.  I'm glad you all stopped me from keeping them in

As far is storing disk SMART logs go, I'm not planning to use any automated script, but instead have already made up an excel spreadsheet posted next to the computer, and plan on checking disk status through BubbaRAID's menu every month or two and writing down the date and any new differences/errors.  Slightly more work on my part, but it encourages me to keep more of an eye on the servers than letting the logs accumulate until something goes wrong   (I saw BubbaQ's SMART reports package, but I'll think I'll pass on it, especially if the long smart test doesn't offer much benefit over a standard parity check)  Once the systems get 10+ drives each, and have been running stably for a year or two, I might reconsider.

I went through the automation links given, and while I understand the theory behind them, I'm not sure how to implement them in practice (hence the original plan of putting everything into the go script)

Still, I'll give it a shot, since that seems to be the preferred method now:  (please correct as necessary - in particular, I'm not sure I started out rc.d script correctly and put in the correct setup in the go script)

First, I want to create a directory in /boot/custom/etc/ called 'rc.d'

in this directory, I want a file called 'ServerStartup.sh'

within this file, I want to type:

crontab -l >/tmp/crontab

# parity checks on the 1st and 14th at 3am
# user notice of check
echo "# check parity on the 1st and 14th of every month at 3am:" >>/tmp/crontab
# check command
echo "0 3 1,14 * * /root/mdcmd check 1>/dev/null 2>&1" >>/tmp/crontab

#set up rsync between the two servers every other day at 3 am - will be commented out for Server2 go script
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk1/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk2/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk3/*" >>/tmp/crontab

crontab /tmp/crontab

While I'm at it, I'll probably want to move the unMENU boot call over to the script too, but that will just be a matter of cutting/pasting from the current go script

Next, I want the rsync.conf file (both of them) as described in post #1 (unchanged?)

Finally, in my go script I'll want to add to the end:

fromdos < /boot/custom/etc/rc.d/ServerStartup | sh

(whats the fromdos syntax for?  Why can't I just use  /boot/custom/etc/rc.d/ServerStartup.sh

Also, I'm still confused as to how to set up rsync - will what I have above work?  (see also questions from post#1)  How will it know where to copy the data to?  (The way I have it set up, for example, it seems to be taking data from server1 disk1 and copying it server2, but not necessarily server2 disk1)

(whats the fromdos syntax for?  Why can't I just use  /boot/custom/etc/rc.d/ServerStartup.sh

This FAQ entry should help clarify the need for fromdos and todos.

I figured it'd be something like that - I was planning to use Notepad++ and save the file without carriage returns anyway.

problem more or less solved

Still, I'll give it a shot, since that seems to be the preferred method now:  (please correct as necessary - in particular, I'm not sure I started out rc.d script correctly and put in the correct setup in the go script)

 

First, I want to create a directory in /boot/custom/etc/ called 'rc.d'

 

in this directory, I want a file called 'ServerStartup.sh'

 

within this file, I want to type:

crontab -l >/tmp/crontab

# parity checks on the 1st and 14th at 3am
# user notice of check
echo "# check parity on the 1st and 14th of every month at 3am:" >>/tmp/crontab
# check command
echo "0 3 1,14 * * /root/mdcmd check 1>/dev/null 2>&1" >>/tmp/crontab

#set up rsync between the two servers every other day at 3 am - will be commented out for Server2 go script
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk1/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk2/*" >>/tmp/crontab
echo "0 3 2-6,8-13,15-20,21-31 * * /usr/bin/rsync rsync://Server2/disk3/*" >>/tmp/crontab

crontab /tmp/crontab

While I'm at it, I'll probably want to move the unMENU boot call over to the script too, but that will just be a matter of cutting/pasting from the current go script

 

Next, I want the rsync.conf file (both of them) as described in post #1 (unchanged?)

 

Finally, in my go script I'll want to add to the end:

fromdos < /boot/custom/etc/rc.d/ServerStartup | sh

 

(whats the fromdos syntax for?  Why can't I just use  /boot/custom/etc/rc.d/ServerStartup.sh

 

Also, I'm still confused as to how to set up rsync - will what I have above work?  (see also questions from post#1)  How will it know where to copy the data to?  (The way I have it set up, for example, it seems to be taking data from server1 disk1 and copying it server2, but not necessarily server2 disk1)

OK, i will try to outline as best i can how the Third Part Boot Architecture works and how you need to set this up.

1.  Create the structure at the root of your flash drive that looks like:

/custom/etc/rc.d

2.  In this folder place a script called rc.local_startup and this script should contain this code:

#!/bin/bash
logger -trc.local_startup -plocal7.info -is "Initiating Local Custom Startup."
scripts=`ls /boot/custom/etc/rc.d/ | egrep -v "rc.local_startup|rc.local_shutdown"`
cd /boot/custom/etc/rc.d
for script in $scripts
do scriptbase=${script##*/}      # Strip pathname
  ( echo "Processing $script" 
fromdos < $script | sh -xv
  ) 2>&1 | logger -t$scriptbase -plocal7.info -is
done

3.  Now, what you need to do is separate the things you want to do into different files. Put the parity check stuff in its own file and call it S70-parity_check (name does not really matter but try to stick this naming scheme).  Also put the rsync stuff in its on file and name it accordingly. My parity check script looks like this:

#!/bin/sh
crontab -l >/tmp/crontab
grep -q "/root/mdcmd check" /tmp/crontab 1>/dev/null 2>&1
if [ "$?" = "1" ]
then
   echo "# check parity every Sun at 1 am:" >>/tmp/crontab
   echo "0 1 * * 0 /root/mdcmd check 1>/dev/null 2>&1" >>/tmp/crontab
   crontab /tmp/crontab
fi

*** Like I said earlier I also have files that you can find in the thread i linked above.  For me the update hosts one is needed and the S01-blockdev one is also needed.  Feel free to ask some questions about them but it usually does not hurt to have them in the folder***

4.  That should get you started and hopefully explains it a little bit better.

Actually, I ended up basically doing this - but instead of putting in separate scripts, I just put all my personal startup items into a single rc.local script and called that from go (I found it easier that way).  If I ever need to add on more custom user scripts, I'll modify the go script to call whatever is in the rc.llocal folder instead of just the one script - thanks for replying though

Actually, I ended up basically doing this - but instead of putting in separate scripts, I just put all my personal startup items into a single rc.local script and called that from go (I found it easier that way).  If I ever need to add on more custom user scripts, I'll modify the go script to call whatever is in the rc.llocal folder instead of just the one script - thanks for replying though

Not a problem, figured i would try to better explain the Third Party Boot Architecture.

The way you are doing it works just fine, but adding excessive lines to the go script was the reason for the creation of the fromdos line and the rc.local_startup file.  The code in that file will run any files (with or without a .sh ending) in the rc.d folder.  The "separation" of and specialization of each file was/is the goal of this structure.  It makes diagnosing users problems much easier.

makes sense - I've taken everything except the folder pointer (and BubbaRAID's tasks that it put there) out of the go script - you're right - it looks much neater that way - plus, if i update unRAID and it overwrites the go script - it's much easier to just put the one line in than rewrite all the other commands.

makes sense - I've taken everything except the folder pointer (and BubbaRAID's tasks that it put there) out of the go script - you're right - it looks much neater that way - plus, if i update unRAID and it overwrites the go script - it's much easier to just put the one line in than rewrite all the other commands.

That's the goal.  I am glad you got it working and that everything is how you need it.  Feel free to ask if you have any more questions and we (the community) will help as best we can.

Sounds to me like we need an advanced tab / Maintenance settings page in unraid where you can set all this stuff.

Try to avoid forcing the end user to go to the cmd line, especially if they are used to working in windows (cringe).

So crontab, go script, other commands to run at boot time.

It would be a nice feature, not hard to make.

Now, other than unmenu and bubba Raid, are there any other add-on's or ports of unraid?

Has anyone made a precompiled sabnzb addon?

I have yet to build a full dev slackware version of unraid. Where does the time go...