Thanks for all your help! Unfortunately a) I had auto update to off., and b) Even removing that entry from the crontab does not work (cron only calls it once per day → 0 0 * * *) - Something else must be calling that script :robotsad:
Given that - I would recommend anyone reading to avoid 1.04.04 if they need a crontab.
Yes, I agree. Have you examined what processes you got running (ps -ef)? That should give you more clues on this.
I did look through them, but there was no obvious sign (at least from the process name) what might be the culprit.
_ ~ # ps -ef _
_ PID USER VSZ STAT COMMAND _
_ 1 root 2612 S init _
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
6 root 0 SW< [cpuset]
7 root 0 SW< [khelper]
8 root 0 SW [kdevtmpfs]
9 root 0 SW< [netns]
10 root 0 SW [kworker/u:1]
155 root 0 SW [sync_supers]
157 root 0 SW [bdi-default]
159 root 0 SW< [kblockd]
164 root 0 SW< [ata_sff]
175 root 0 SW [khubd]
178 root 0 SW< [md]
193 root 0 SW< [rpciod]
209 root 0 SW [kswapd0]
210 root 0 SW [fsnotify_mark]
211 root 0 SW< [nfsiod]
213 root 0 SW< [xfs_mru_cache]
214 root 0 SW< [xfslogd]
215 root 0 SW< [xfsdatad]
216 root 0 SW< [xfsconvertd]
217 root 0 SW< [crypto]
372 root 0 SW [scsi_eh_0]
375 root 0 SW [scsi_eh_1]
378 root 0 SW [kworker/u:2]
381 root 0 SW< [target_completi]
382 root 0 SW [LIO_rd_mcp]
392 root 0 SW [mtdblock0]
397 root 0 SW [mtdblock1]
402 root 0 SW [mtdblock2]
407 root 0 SW [mtdblock3]
412 root 0 SW [mtdblock4]
417 root 0 SW [mtdblock5]
422 root 0 SW [mtdblock6]
486 root 0 SW [flush-1:0]
512 root 0 SW [ubi_bgt0d]
517 root 0 SW [ubifs_bgt0_0]
1962 root 0 SW< [loop0]
_ 2242 root 2556 S xmldb -n config _
_ 2245 root 2236 S xmldb -n config -s /var/run/xmldb_sock_wto _
_ 2375 root 2216 S up_read_daemon _
_ 2376 root 1944 S up_send_daemon _
_ 2537 root 2612 S /sbin/udhcpc -R -r 192.168.0.101 -i egiga0 -x hostname Cloud -p /var/run/udhcpc0.pid -s /usr/share/udhcpc/default.script -b _
_ 2597 root 2456 S /usr/sbin/syslogd -r -m 0 --rt_line 800 _
_ 2673 root 2036 S mserver _
_ 2690 root 13724 S mail_daemon _
2772 root 0 SW [md0_raid1]
2785 root 0 SW [jbd2/sda4-8]
2786 root 0 SW< [ext4-dio-unwrit]
2791 root 0 SW [jbd2/sdb4-8]
2792 root 0 SW< [ext4-dio-unwrit]
2800 root 0 SW [md1_raid1]
2808 root 0 SW [jbd2/md1-8]
2810 root 0 SW< [ext4-dio-unwrit]
_ 2842 messageb 3328 S /usr/bin/dbus-daemon --system _
2845 root 3964 S avahi-daemon: running [Cloud.local]
_ 2852 root 5488 S /usr/sbin/sshd -f /etc/ssh/sshd_config _
_ 2941 root 4484 S fan_control 0 c _
_ 2944 root 4288 S set_pwm _
_ 2954 root 5396 S sysinfod _
_ 2965 root 2236 S xmldb -n config -s /var/run/xmldb_sock_sysinfo _
_ 3033 root 4564 S /usr/sbin/lighttpd-angel -D -m /usr/lighty_lib -f /etc/lighttpd/lighttpd.conf _
_ 3081 root 4504 S system_daemon _
_ 3085 root 4340 S chk_io _
_ 3130 root 7188 S N /usr/local/orion/communicationmanager/communicationmanager -f 120 _
_ 3153 root 2612 S init _
_ 3171 root 8500 S /usr/sbin/lighttpd -D -m /usr/lighty_lib -f /etc/lighttpd/lighttpd.conf _
3203 root 33932 S php-fpm: master process (/etc/php//php-fpm.conf)
_ 3552 root 2612 S {mysqld_safe} /bin/sh /usr/bin/mysqld_safe --user=root --datadir=/mnt/HD_a4/.@database@ _
_ 3652 root 30668 S /usr/libexec/mysqld --basedir=/usr --datadir=/mnt/HD_a4/.@database@ --user=root --log-error=/mnt/HD_a4/.@database@/Cloud.err --pid-file=/mnt/HD_a4/.@database@/Cloud.pid _
_ 3770 root 69888 S upnp_nas_device -webdir /etc/upnp _
_ 3783 root 3692 S apkg _
_ 3899 root 32652 S /usr/local/wdmcserver/bin/wdmcserver -v:/tmp/Volumes.xml _
_ 4015 root 41800 S /usr/local/wdmcserver/bin/wdphotodbmerger _
_ 4054 root 9400 S /usr/local/bin/wdnotifier _
_ 4802 root 23392 S smbd -D _
_ 4829 root 15712 S nmbd -D _
_ 5136 root 1792 S chk_blockip _
5148 root 9960 S pure-ftpd (SERVER)
_ 5369 root 5392 S /usr/sbin/netatalk -F /etc/netatalk/afp.conf _
_ 5377 root 8472 S /usr/sbin/afpd -d -F /etc/netatalk/afp.conf _
_ 5754 root 13356 S httpd _
_ 6061 root 4984 S scheddler _
_ 6129 root 13488 S httpd _
6189 root 0 SW [kworker/0:2]
_ 6202 root 2324 S xmldb -n config -s /var/run/xmldb_sock_vv _
_ 6253 root 2236 S xmldb -n config -s /var/run/xmldb_sock_usbdev_info _
_ 6273 root 4032 S chk_hotplug _
6362 root 0 SW< [iscsi_eh]
_ 6412 root 4764 S iscsid _
_ 6413 root 5216 S < iscsid _
_ 6604 root 13356 S httpd _
_ 6758 root 5420 S /usr/sbin/cnid_metad -d -F /etc/netatalk/afp.conf _
_ 8015 root 26012 S /usr/sbin/cnid_dbd -F /etc/netatalk/afp.conf -p /mnt/HD/HD_a2/Photos -t 7 -l 5 _
8150 root 0 SW [kworker/0:0]
_ 11660 root 2732 S crond _
_ 11683 root 2296 S noip2 -b -f 34560 _
11888 root 0 SW [flush-9:1]
11921 root 0 SW [kworker/0:1]
_ 12334 root 7928 S sshd: sshd@ttyp0 _
_ 12370 root 2736 S -sh _
_ 12418 root 2736 R ps -ef _
_ 14705 root 35588 S php-fpm: pool www _
_ 15674 nobody 22152 S /usr/sbin/afpd -d -F /etc/netatalk/afp.conf _
_ 27008 root 36100 S php-fpm: pool www _
EDIT: Editing my reply - since my last one didn’t provide anything relevant and was unnecessarily long. Anyway, looking at your process listing I don’t see any except the httpd that are different than mine…and obviously I don’t expect that one to be an the issue. So, sorry, this cron issue might not be solved very easily.
So I’ve done my last bit of digging I think, and here are the findings.
It looks like there are quite a few binaries that kill and restart crond!
A quick grep of files within directories in /usr/local/modules came up with the following:
cgi/wizard_mgr.cgi:kill -9 pidof crond
cgi/wizard_mgr.cgi:crond&
cgi/system_mgr.cgi:kill -9 pidof crond
cgi/system_mgr.cgi:crond&
usrlib/libctc.so:killall crond ; crond
Further, based on some of the greps, it appears that one of these binary files builds the crontab from the config XML file + some static entries(see an exert from open one of the binaries in vi that restart the cron service - this is just my guess based on the cat, etc).
@^@cat %s > %s^@/usr/local/modules/files/static_crond_list^@^@/var/spool/cron/crontabs/root^@^@^@a+^@^@quota_monitor^@^@^@0 3 * * 1 getHddWhiteList.sh
^@^@^@killall crond ; crond^@^@^@access_mtd “cp /etc/NAS_CFG/config.xml /usr/local/config”^@^@^@/system_mgr/crond/%s/item:%d^@^@^@^@0^@^@^@^H.^A…^
Now, I know we noted that not all the entries were in that XML; alas the other two are found in here:
/usr/local/modules # ls -ltr /usr/local/modules/files/static_crond_list
Which is on a read only mount! 
As I said very early on, right in my second post…the ONLY way for you to solve this issue would be to bake-in your cron changes into the firmware’s source code. All these digging will give you clues and maybe even some answers but not the solution. I do think that would be your best solution in this case, since cron is wiping itself off. Having your own job right in the cron’s original list of jobs will keep your job running all the time even when the cron tab file gets reset every half hour or so. It is rather unfortunate that WD has implemented such a stupid solution for whatever they are trying to achieve by wiping cron itself. Gives very little room for our own solutions.
You probably will want to try this (at your own risk)… It’s just what I did and it works. Even after reboots.
Go to /usr/local/config and edit the config.xml file by adding an entry in the section of the XML.
7
user.log
stime
wd_crontab
app_get_info
auto_fw
surveillance
random_check
fw_available
…
3
<1>*/5</1>
<2>*</2>
<3>*</3>
<4>*</4>
<5>*</5>
cd /shares/Public/Surveillance;python capture.py
The entry is to be inserted at the same level as the entry, i.e. as a direct child of . Notice that the name of the task’s xml element is the name you put in between and in the crond/list/name element.
This way the config retained.
After a reboot, if you look around at config.xml, you might discover that your added entry may be rearranged. But that should be ok as long as everything is still there.
Have Fun!
Excellent workaround siamese. I should have thought of this alternative solution.
I do recommend creating a backup of the original /usr/local/config/config.xml before editing that. What happens on reboot is that this file gets copied over to /etc/NAS_CFG/config.xml and settings from that config.xml are then read from and used. So yes, this would allow you to have a persistent cron job.
jacksparrow - I finally decided to update to the latest firmware (1.04.05) and I noticed that before even I put in my custom changes in the firmware, the stock firmware does not appear to be updating crontab every 30 mins. Not sure what was happening with the previous firmware as I never installed it, but thought you might want to know about the current firmware.
After verifying that crontab isn’t losing anything on it’s own even after 30 minutes have elapsed, I then removed three jobs at the startup in my custom firmware code:
0 3 * * * /usr/sbin/traceroute_wd.sh &
0 3 * * * wd_crontab.sh&
0 0 * * * random_check -s &
Thanks guys! I haven’t had a chance to try the replacement solution (was out of town). I will give the new firmware a try tonight.
Is there a tutorial somewhere on how to bake changes into firmware?
Hey Guys,
I wonder if there’s a setting triggering this in the stock config - even with the updated firmware - I’m noticing cron being reset:
_ ~ # ls -ltr /var/spool/cron/crontabs/root _
_ -rw------- 1 root root 391 Aug 19 20:15 /var/spool/cron/crontabs/root _
_ ~ # date _
_ Tue Aug 19 20:45:54 EDT 2014 _
_ ~ # ls -ltr /var/spool/cron/crontabs/root _
_ -rw------- 1 root root 391 Aug 19 20:45 /var/spool/cron/crontabs/root _
Nope…with stock config my cron wasn’t being reset. In fact, my suspicion last night was that even in previous firmware it wasn’t being reset, but I never applied the previous firmware so couldn’t confirm it. I think you have something a bit different. Something you might have modified maybe. I don’t know what it could be. The one other thing that may or may not be relevant is that I don’t have send notifications/alerts turned off. But I’m leaning towards that having no impact on this. I really waited to be sure well past the 45-minute mark and the timestamp for the very file you mentioned above remained unchanged. I unfortunately have no idea what’s different on your system that’s making this behave differently. That job of yours that you wanted to run…make sure that is completely off of cron. Also, I highly recommend you shutdown your EX2…not a reboot but a shutdown and then turn it back on after a couple minutes.
jaclsparrow - I meant to write this sooner but somehow forgot.
I spoke too soon with my last reply - I stand corrected. You were correct. It does appear that something in EX2’s frmware constantly keep putting those jobs back - the only thing I have noticed is that it takes several hours and is not within the much shorter 30-minute window that you described. That is why I did not see it in the 45-minute trial window I tested it with. But I do see that sometime after 3-5 hours those pesky jobs come back.
So I am about to take a stronger approach this time and basically have a job myself that wil run every hour and all it will do is update cron to MY list of jobs - removing those annoying jobs. I will probably end up finding that whatever is updating cron will still update cron and therefore remove my cron-update job and thus my cron will no longer keep only my specified jobs. And if that happens, I have another idea up my sleeve.
Hi,
I tried this solution on a WD My Could Mirror over ssh, and after rebooting, i can’t access the machine anymore.
Neither can my collegue who’s at the location of the server. They tried to access it directly on http://wdmycloudmirror.local/ and that doesn’t work.
It looks like modifying the config damaged the machine, how should I recover it?
Thank you
If I reset the machine through the reset button, will that erase the data?
Reset button doesn’t erase data but wipes all settings, including users and brings the device’s config to factory settings. If the changes you tried broke it, then obviously you did something wrong…but nothing that was mentioned should have affected the functioning of EX2 except cron behavior. If you do these things, you gotta have a good idea what you are doing…or else don’t attempt them.
Thank you for your reply
Having a good idea of what I’m doing is all relative, I had the same issue as many, my cronjobs where not persisting so I tried to edit config.xml as mentionned in this thread. I added the lines corresponding to the cronjob I wanted to set up.
I then rebooted the machine but was not able to access it again, locally or remotly.
I have a My Could Mirror not EX2.
It looks like the booting failed, is there any way to get out of there? The data need to be recovered.
I saw here http://community.wd.com/t5/WD-My-Cloud/Admin-password-after-paper-clip-reset/td-p/699658/page/3 that My Could has a 40s reset as well, could that reset the config and preserving the data?
Or is there any way to access the machine to fix this?
Thanks
Ok so doing the 40s reset worked, I could access the machine again.
I still don’t know what went wrong in setting up those cronjobs though
Mirror and EX2 should behave identically in this regard…so it doesn’t matter.
The ONLY way for me or nobody else to be able to say what went wrong is to see exactly what you replaced in the config file and with what. Saying that you followed the directions outlined by the other poster tells me very little. A single missing character could make all the difference. And now that you have reset your Mirror, you don’t have the broken config file anymore…so unless you backed up the original one and your modded one and can post the relevant sections here, it’ll be impossible to trace what went wrong. You can always attempt it again…this time backing up the files outside of the device as well, for later troubleshooting if need be. All I can say is, I’ve been modding the config file since EX2 came out almost 6 months ago but it has never rendered my device unreachable.
Thanks for your help, I can tell you by memory the exact changes I did and didn’t:
First I forgot to edit the count :
7
Could have this cause the reboot to fail?
Second I added the following line in :
rsync
And the following item at the bottom of the cronjobs
3
<1>*/5</1>
<2>*</2>
<3>*</3>
<4>*</4>
<5>*</5>
bash /home/root/rsync.sh
Then I saved the file and I hit
#reboot
I didn’t do the #sync since I didn’t think that was necessary, maybe that’s what caused the failure as well?
| 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
|