DSM-G600, DNS-3xx and NSA-220 Hack Forum

Hi stevelucky,

have a look at the following thread http://dns323.kood.org/forum/t265-littl … ccess.html

cron jobs will get lost following a reboot, thus a script is used to set up the cron jobs once the dns-323 restarts.
I use the so called "time machine" backup in my signature, maybe that would give you better results.

good lucky

Actually, this doesn't fix my problem. I set everything up, just as you had outlined. I reboot my 323, and I can see the cronjob, by running crontab -l. As soon as I log in to the 323 interface, the cronjob disappears (I confirm this by running crontab -l, again). Or if I access it via the finder, it disappears as well. Why would accessing the 323 cause the cronjob to disappear?

I'll give that a shot. So, where should I put that in the script? Does it matter where it's placed?

So, like this?

#!/bin/sh

CRONTXT=/mnt/HD_a2/crontab.txt

# start with existing crontab
/bin/crontab -l > $CRONTXT

# wait 3 minutes before running the script
/ffp/bin/sleep 3m

# 1. add the Rsync job to execute at 2:05 am 2. Create a logfile (append to any existing log file) 3. Create a backup directory on Vol_B for deleted files
# note: use a single > after /mnt/HD_b2 if you want to a create a new log file each night with no append

/bin/echo "45 10 * * * /mnt/HD_a2/ffp/bin/rsync -av --delete --backup --backup-dir=../backup_rsync_save/`date +%Y-%m-%d` /mnt/HD_a2/* /mnt/HD_b2/rsync_save >> /mnt/HD_a2/ffp/log/rsync.last.log 2>&1" >> $CRONTXT

# install the new crontab
/bin/crontab $CRONTXT

# clean up
/bin/rm $CRONTXT

Last edited by stevelucky (2010-09-20 20:24:34)

No problem, glad it worked. BTW - it doesn't really matter where you put it in the script as long as it is before

# install the new crontab
/bin/crontab $CRONTXT

To cover the unlikely event that something else goes on, I'd suggest moving it above
# start with existing crontab
/bin/crontab -l > $CRONTXT


On another note, I found a way to set this up so that I can edit and rerun the script numerous times to test it out. Without any changes, you will duplicate the new cron entries, which obviously would not be good.


What you can do, is run 'crontab -l' on its own and count the number of default lines (it changes depending on what options / configuraiton you have). Between my 2 NAS units, it is either 5 or 6 (one is Raid 1 and the other is independant drives). Then modify the line that saves the cron entries as follows:

/bin/crontab -l|head -n 5 > $CRONTXT

Change the "5" above to the number of lines. This will strip out any extra entries before appending the new ones allowing you to run the script as many times as required to test different settings etc.

I'm sure you could get really fancy, but personally I only reboot every couple of months so a 3 minute delay is no big deal. Also, my jobs run at night so as long as I reboot in the day it is just fine.

The ability to edit the script and rerun it without rebooting is more important to me and that is why the "head" command helps in my situation more than the sleep.

Last edited by FunFiler (2010-09-21 21:10:11)

This script only sleeps, writes stuff to a file which is later deleted, it doesnt modify crontab.

#!/bin/sh

# wait 3 minutes before running the script
/ffp/bin/sleep 3m

CRONTXT=/mnt/HD_a2/crontab.txt

# install the new crontab
/bin/crontab $CRONTXT

# start with existing crontab
/bin/crontab -l > $CRONTXT


#add backup specific folders of Volume_1 (/mnt/HD_a2) to Volume_2 (/mnt/HD_b2) at
/bin/echo "15 15 * * * /ffp/bin/rsync -av -delete /mnt/HD_a2/testt /mnt/HD_b2/testt" >> $CRONTXT

/bin/crontab $CRONTXT

# clean up
/bin/rm $CRONTXT

Last edited by bjby (2011-12-13 22:13:09)

He added a line after the backup line was appended to the crontab file that would reload the modified crontab file.

That being said, I still don't think it is right. 

The lines:

# install the new crontab
/bin/crontab $CRONTXT

shouldn't be done before the file $CRONTXT is created.  Crontab just reports an error about a missing file and leaves the in-memory crontab alone, so no harm.

How about:

#!/bin/sh

# wait 3 minutes before running the script
/ffp/bin/sleep 3m

CRONTXT=/mnt/HD_a2/crontab.txt

# Write out the original DLink firmware crontab
/bin/crontab -l > $CRONTXT

#add backup specific folders of Volume_1 (/mnt/HD_a2) to Volume_2 (/mnt/HD_b2) at
/bin/echo "15 15 * * * /ffp/bin/rsync -av -delete /mnt/HD_a2/testt /mnt/HD_b2/testt" >> $CRONTXT

# install the new crontab
/bin/crontab $CRONTXT

# clean up
/bin/rm $CRONTXT


Untested....

Tnx, it survived the reboot- it works. yay!