I’m trying (well quasi-succeeding) in adding crontab entries to my EX2 using the usual fashion (crontab -e). The entries take and cron tasks are run properly. Unfortunately the crontab list reverts on a regular basis (i.e., within an hour or 2 of being set).
Does anyone know how to add cron entries that will not be reverted on this box?
I am curious - what job are you trying to add to crontab?
Cybernut1,
Long story short, the public link sharing with the WD My Cloud app is a bit limited (it can only share a single file or single folder). It also, due to the way the hash is generated, does not allow any way for files to have an expiry date when being shared.
What I’ve done is built a quick app that runs on my desktop/laptop machines on the network to allow this type of sharing (similar to the dropbox approach - right click on a file or series of files and click “share”). It uses the native hash generation provided by WD, but each time I “share” a file, it creates a new folder on a different mount with the files to be shared. I also creates a file that corresponds to the expiry date of the link.
What I need the cronjob for is to periodically run a script to check the expiry date of each publically shared file(s) and remove the shared files that have passed the expiry date. Since the network machines are not always on, the cronjob on the NAS seems to be the most logical place to run it.
I see. Okay, there is one way you certainly can make cron job persistent on reboot - and it is to ‘bake’ it in the firmware source code and compile it (code available from WD’s site’s downloads section).
I just put in a simple cron job in mine to see if the cron does lose the change over the next few hours…for that is not what I’d expect unless I have rebooted the EX2 or have a scheduled shutdown every night or something. I’d expect any cron job I add to persist until reboot. You seeing that the cron loses your change without a reboot is really odd.
It wasn’t what I would expect either :smiley:
I just checked my system uptime to be doubly sure the box wasn’t rebooting on me without noticing and its been up for 5+ days and counting (3 days longer than my latest cron update). Also, I’ve tried the alternate route (adding a file with a cron entry to /etc/cron.d); it seems that doesn’t get removed (but is not run either).
The only other item I found was that the stock cron entries are coded up in XML in /etc/NAS_CFG/config.xml (along with numerous other configuration settings). Is it possible something is periodically parsing these file to generate the crontab?
Aah yes, the entries in the config.xml. Good point. I had seen that. That is possible - BUT in mine I also see an additional entry/job (getHddWhiteList.sh) which I have always seen anytime I listed my cron jobs and that is not in the config.xml. So I don’t think whatever parses those xml entries puts ALL the jobs there. There can (and should be) oher jobs that can be added to cron as root.
I’ll let mine run and post my test results back in 6 hours or so - you have seen your cron never keep yourt job for that long, right? If needed, I can run it even longer - but I’ll find out what happens.
I have not measured the exact time, but last time it was about 2.5-3 hours. I’ve added another every minute cron entry to touch a file (to get a better measurement of when it stops).
BTW, the following command should tell you when the crontab was last edited (by root):
ls -la /var/spool/cron/crontabs/root
I will probably monitor that timestamp as well…after all THAT is the crontab file itself.
jacksparrow wrote:
I have not measured the exact time, but last time it was about 2.5-3 hours. I’ve added another every minute cron entry to touch a file (to get a better measurement of when it stops).
Very good idea.
So the plot thickens…
/tmp # ls -ltr *mycron
-rw-r–r– 1 root root 0 Aug 12 18:15 startmycron
-rw-r–r– 1 root root 0 Aug 12 18:42 stopmycron
/tmp # date
Tue Aug 12 19:25:10 EDT 2014
/tmp # ls -ltr /var/spool/cron/crontabs/root
-rw------- 1 root root 391 Aug 12 19:12 /var/spool/cron/crontabs/root
startmycron was created with a _ "t** ouch /tmp/startmycron**" before editing the crontab (crontab -e).**stopmycron **was created/maintained with a "** touch /tmp/stopmycron"**_ scheduled every minute as a cron task.
So it was less than 30 minutes this time (although I will admit I never “clocked” the time last time). More interestingly, it looks like cron was touched after (so a second time) i.e., 18:42 vs. 19:12. The time stamp is 30 minutes after my stopmycron job. I’ll keep an eye out if this happens every 30 minutes (i.e., theres another stamp at 19:42)
I’m convinced I was not correct with the 2.5hours… Another 30minute edit.
/tmp # ls -ltr /var/spool/cron/crontabs/root
-rw------- 1 root root 391 Aug 12 19:42 /var/spool/cron/crontabs/root
Hmm…that’s interesting.
In my case, I had set up an hourly job (since I didn’t expect it to toss out my cron job) and so far it’s holding steady at just past the 4-hour mark. I had basically set up a simple cron job to spit out to temp.txt file the current time at every 16 minutes past the hour - crontab was last edited at 16:14 local time.
My output showing everything going fine so far:
/var/log # ls -la /var/spool/cron/crontabs/root
-rw------- 1 root root 273 Aug 12 16:14 /var/spool/cron/crontabs/root
/var/log # cat temp.txt
Tue Aug 12 16:16 :01 EDT 2014
Tue Aug 12 17:16 :01 EDT 2014
Tue Aug 12 18:16 :01 EDT 2014
Tue Aug 12 19:16 :01 EDT 2014
Tue Aug 12 20:16 :01 EDT 2014
But I am not running the latest firmware. I had updated to the then-latest firmware a month ago to check if WD had fixed an ftp bug and after testing and finding they hadn’t, I reverted back to the then-previous version (now two versions old) firmware (because I have custom code built-into my firmware and have not built them yet into the newer firmware versions). I wonder if this is a phenomenon with the latest firmware. I will keep monitoring and report back here if I find something odd but so far I am not seeing anything odd with cron yet. If another person who IS running the latest version volunteers to do tests like this, then that would be great. Then that could point to perhaps some changes with the newer firmware that’s causing this.
I would also suggest if you can perhaps reboot your EX2 and see if the cron problems persist. I know there’s no reason for it to behave any differently after rebooting - but just wondering if something odd has happened. Rebooting will reset the whole crontab file and cron process (in my case since I have my custom changes baked-in I don’t worry about losing all that after a reboot).
Thanks for running the test.
I’m rebooting now to try that theory. I don’t expect any changes either. For everyone’s reference I am running the latest firmware 1.04.04.
There is only one line in the crontasks that executes every 30 minutes:
_ */30 * * * * /usr/sbin/quota_monitor _
It’s symlinked to a binary file so I can’t really decode what its doing (but given the file name, I doubt its related)
Aah, yes, I don’t have that quota_monitor job in my crontab. I do recall seeing in the release notes of one of the last two firmware releases that they fixed the quota monitoring bug (so I guess it never worked in the older versions - including the one I am on) but yes, I agree, that should be unrelated to cron’s behavior. Cron process should behave as expected and retain all jobs added to the crontab file. Unless one of those processes in the newer firmware is actually rewriting the crontab file itself - which would be a downright stupid thing to do…but I won’t be surprised if they did something like that 
Cybernut1 wrote:
Aah, yes, I don’t have that quota_monitor job in my crontab. I do recall seeing in the release notes of one of the last two firmware releases that they fixed the quota monitoring bug (so I guess it never worked in the older versions - including the one I am on) but yes, I agree, that should be unrelated to cron’s behavior. Cron process should behave as expected and retain all jobs added to the crontab file. Unless one of those processes in the newer firmware is actually rewriting the crontab file itself - which would be a downright stupid thing to do…but I won’t be surprised if they did something like that
That was the only entry with a 30 minute interval, I changed it to every minute as an experiment to see if something was baked into it (but its been 5+ minutes with no reset yet… so I guess that isn’t it either 
Yes…must be something else.
Well, let’s see if the 30-minute (or even the 2-1/2 hour) reset returns. If not, then the reboot must have fixed some kind of temporary glitch with cron. If it doesn’t, then there is definitely an issue with cron in the current firmware. And WD needs to fix that - even if cron still won’t be persistent after reboots…at least it should be persistent between reboots.
BTW, these are all the jobs on my cron (two firmware versions behind you) - and the last one is the one I added to test this issue - so hopefully you don’t have any other additional ones besides the quota_monitor one:
*/10 * * * * /usr/sbin/rlog -s /usr/local/modules/files/syslog_rotate.conf
30 2 * * * /usr/sbin/stime&
0 3 * * * wd_crontab.sh&
0 3 * * * auto_fw -c 1&
0 4 * * * auto_fw -a -c&
*/10 * * * * ddns-start&
0 3 * * 1 getHddWhiteList.sh
16 * * * * /usr/local/config/testcron.sh&
So it’s still resetting. Also, it looks like the crond service is restarting (and its .pid file in /var/run is being updated)
_ /var # ls -ltr /var/spool/cron/crontabs/root _
_ -rw------- 1 root root 392 Aug 12 21:10 /var/spool/cron/crontabs/root _
_ /var # ls -ltr /var/run/crond.pid _
_ -rw-r–r– 1 root root 6 Aug 12 21:10 /var/run/crond.pid _
The native cron is as follows (only the quota monitor is being called every 30min)
_ 0 3 * * * /usr/sbin/traceroute_wd.sh & _
_ */30 * * * * /usr/sbin/quota_monitor & _
_ */10 * * * * /usr/sbin/rlog -s /usr/local/modules/files/syslog_rotate.conf _
_ 30 2 * * * /usr/sbin/stime& _
_ 0 3 * * * wd_crontab.sh& _
_ 0 4 * * * auto_fw -a -c& _
_ 0 0 * * * auto_clear_recycle_bin.sh & _
_ 30 3 * * * /usr/sbin/chk_wfs_download& _
_ 0 0 * * * random_check -s & _
_ 48 23 * * * auto_fw -c 1 & _
_ 0 3 * * 1 getHddWhiteList.sh _
So I’ve narrowed it down to the random_check call (/usr/sbin/random_check). Ran this manually and each time it rebuilds the crontab AND restarts the service. It may be doing other things. I can’t decode whats going on as it’s a binary.
This still raises a couple questions:
That cron entry is set to run once a day at midnight… but yet its running every 30 minutes, so is something else calling it?
Whats the purpose?
For further reference:
/var/spool/cron/crontabs # random_check -h
“random_check -c” : Set crontab by myself
“random_check -s” : Set random time to check firmware information from WD server
“random_check -d” : Delete crontab setting
“random_check -h” : Show message
Hmm…interesting - and just as I thought…one of cron’s own processes is rewritng the crontab file - a really stupid thing to do.
Now that you mention it, I do have firmware auto update turned OFF (otherwise my custom firmware would be overwritten). And I thought all this time that one of the other cron jobs, the auto_fw is responsble for checking the firmware. I just found out it does so - but also has other purposes:
~ # auto_fw -h
***For FW Auto Upgrade***
“auto_fw -c 0/1(send_alert)” : Check Firmware Version from WD Server, ex: “auto_fw -c 1”
“auto_fw -d 0/1(reboot)” : Download and Install Firmware, ex: “auto_fw -d 0”
“auto_fw -f 0/1(reboot)” : Download and Install Firmware for REST API, ex: “auto_fw -f 1”
" auto_fw -s version" : Simulating fw version, ex: “auto_fw -s 1.01.01”
***For APPs Auto Upgrade***
" auto_fw -a -c" : Check WD Server and Get APPs Xml File
" auto_fw -a -g app_name" : Get Release Note File from WD Server, ex: “auto_fw -a -g WordPress”
" auto_fw -a -d app_name" : Download and Install APP, ex: “auto_fw -a -d WordPress”
" auto_fw -a -t xml_path" : For Test APPs function, ex: “auto_fw -a -t /mnt/HD/HD_a2/Public/WDMyCloudEX4.xml”
***For Others***
" auto_fw -h" : Help
" auto_fw -r" : Remove All Files
This brings me to the very same question that you came to - what could really be the purpose of random_check since you already have ‘auto_fw -c 1’ job run at 11:48 PM every night (which checks for the latest the firmware version)? I tried to run ’ random_check -h’ but I don’t have that program in my firmware version. So we won’t know it’s REAL purpose for sure since it’s a compiled binary…but the help message you diligently found gives us some idea of what it’s purported to do…I just am not sure how much to trust if it really does what it says it does Because there was already such a feature built-in before…so why the need for this job? Seems very fishy to me.
I do recommend the following:
If you are willing to download and install new firmware releases manually, then in Settings → Firmware Update → Auto Update → Enable Auto Update → set it to OFF. Until the firmware is upgraded to the latest, it will indicate that your firmware is out-of-date in an orange alert icon on the dashboard’s login page. Which is actually a good idea anyway…I DO like to know what the changes are in a new firmware version before I blindly install it. And it is a easy as clicking that right arrow on the firmware update section in the web dashboard to initiate the upgrade. Just gives you more manual control.
Remove the random_check job from your cron (I don’t recommend using the random_check -c option but rather editing out the job out of the crontab file).
After this, I believe your cron issues will go away. It will still be a headache for every reboot - but now that you’ve also turned auto-upgrade off, it shouldn’t reboot by itself ever…you’ll always know when it reboots and you’ll just have to remember that you have to do the cron steps yourself manually again after the reboot - both removing this line and adding the script for your timestamp check that you wanted to do originally.
BTW, I just checked - my cron is running fine and that job is still spitting out the timestamp 8 hours in a row:
~ # cat /var/log/temp.txt
Tue Aug 12 16:16 :01 EDT 2014
Tue Aug 12 17:16 :01 EDT 2014
Tue Aug 12 18:16 :01 EDT 2014
Tue Aug 12 19:16 :01 EDT 2014
Tue Aug 12 20:16 :01 EDT 2014
Tue Aug 12 21:16 :01 EDT 2014
Tue Aug 12 22:16 :01 EDT 2014
Tue Aug 12 23:16 :01 EDT 2014
Wed Aug 13 00:16 :01 EDT 2014
If this answer helps resolve your issue for good, only after testing your cron after making those changes, please mark this post as the solution and give me a kudo on this post if you don’t mind (appreciate the other kudo).
| Forums | News and Announcements | Register | Help | Forum Guidelines |
Copyright © 2021 Western Digital Technologies, Inc. All rights
reserved.
|
Trademarks
|
Privacy
|
Community Terms of Service
|
Site Terms of Use
|
Copyright
|
Contact WD
|