Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
Hey guys,
I'm experiencing an issue where crontab will reset itself to its default values (as per below) periodically, over a timeframe of 1-8 hours or so; i.e. I set it before leaving for work, I get home and it's wiped. I set it again that night, and it's gone the next morning.
root@NAS:/mnt/usb/ffp/home/root# crontab -l 30 2 * * * /usr/sbin/stime& */60 * * * * /usr/sbin/getdhcp& 32 2 * * * /usr/sbin/rtc -s 30 2 2 * * /usr/sbin/rtc -c
This occurs with the /ffp/start/editcron.sh script modifications and also with modifications I make manually.
It's not restarting (judging by what I can read from the logs, and the fact that it always runs the editcron.sh on boot - it has the sleep in there to ensure it doesn't modify crontab before crond has fully loaded)
Any ideas?
Cheers,
Klaus
Offline
I am having a similar problem. I do not know what is going on. I think the latest firmware overwriting the crontab every time the web interface is invoked or every time it wakes up. Unfortunately I am unaware of a hook for these events so cannot think of a clean sophisticated solution. However I came up with a brute force solution. See the following script to get the effect of cron:
#! /bin/sh
COMMAND="/ffp/bin/rsync /mnt/HD_a2/ /mnt/HD_b2/ -aH --delete"
HOUR="3"
while [ "1" -eq "1" ]
do
while [ `date +%k` -ne "$HOUR" ]
do
sleep 1800
done
"$COMMAND"
while [ `date +%k` -eq "$HOUR" ]
do
sleep 1800
done
doneYou could use at to invoke it as a background process.
Offline
You know, a lot of people have been mentioning this issue and I don't think that the root cause has been found. I don't have the latest FW, but I but you're right in that the latest FW has something to do with this.
I wonder if you could kick off a never-ending background process from your funplug that would run a script like the one you have posted. But the script would instead run crontab to put back the entries that you want. Then, at least, your crontab is in effect most of the time.
This still leaves a mystery. If you want to investigate, here's something along the lines of what I would try.
General idea is to replace the /bin/crontab with a script that logs when it got invoked.
/bin/crontab is a link to busybox. So, first just mv /bin/crontab to /usr/bin. Then make a script called /bin/crontab that just calls /usr/bin/crontab. Make sure that still works by typing "crontab -l" or something. If still OK, add some lines to the /bin/crontab script to write some log entries to a file that include the time/date.
You then might be able to correlate unwanted crontab resets with something happening on your system, like a specific time of day, using the web interface, each wake-up, etc.
If nothing else, this could tell you more about how often you would need to run your cron restoration script.
I think that this is pretty low risk - you can't damage much, since the files on on the ramdisk. If something gets messed up, reboot.
There are other approaches. Like writing a script to do a crontab -l every few minutes and check the output to see if your commands are there or not, etc.
Offline
karlrado - some good thinking there... Yeah my solution is a bit of a hack... but those are some good ideas to solve the cron issue. So far my hack solution is working for me. So the motivation to tackle this problem is low. I hope your ideas inspire others though. Next time I do a system rebuild....
Offline
PS I forgot to say thanks!!
Offline
Hello All
Took up Karl's advice here. Yeah I didn't seem motivated but it seemed easy enough so giving it a try. It turns out there are two crontab's in the basic ffp 0.5 installation. One in /ffp/bin/ and another in /bin/. In both instances they are symbolic links to /ffp/bin/busybox and /bin/busybox respectively. So I have replaced both crontab links with the something similar to the following:
#!/ffp/bin/bash echo "`date` crontab is called from /ffp/bin/ with the the following '$@'" >> /ffp/home/root/crontab.out /ffp/bin/busybox crontab $@
I will tell you what happens. Regardless the nice thing about this set up is that it leaves a really easy starting point for ensuring custom crontab entries are always added. For now I will keep it as it is. Just want to see when the crontab is called by the system. Will let you all know soon enough.
Mike
Offline
Would cliaz and/or pilotmm please post the version of firmware they are using?
Thanks.
Offline
Sorry for the absenteeism, it's been a tad busy at my end.
I believe I'm running 1.03, however it's on the revision A DNS-343.
Will be back at home with access to test/report my findings on the 5th...my flight got canned, yay Tiger...
Offline
I am running the DNS 323 with firmware 1.09....
I have logged into the website, let the disks go to sleep all sorts of things. Tried changing many settings over and over. All in an attempt to try to force the system to reset the cron file with no success. It seems the problem has gone away?
Offline
Right, confirmed I have 1.03 running.
I've also replaced /ffp/bin/crontab and /bin/crontab with scripts like pilotmm's above.
One thing I noticed while re-setting the cronjobs; my editcron script calls /bin/crontab as opposed to just crontab (which is /ffp/bin/crontab).
I'm leaving it as is for the moment in order to see what exactly is happening, but is another variable to play with.
Offline
the text enclosed in '***' are my comments, added in the post
root@NAS:/mnt/usb/ffp/home/root# cat crontab.out Tue Jul 5 19:30:26 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l' ***run my script to load cron jobs*** Tue Jul 5 19:36:59 AEST 2011 crontab is called from /bin/ with the the following '-l' Tue Jul 5 19:36:59 AEST 2011 crontab is called from /bin/ with the the following '/mnt/usb/crontab.txt' Tue Jul 5 19:37:03 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l' ***all my modifications are there*** Wed Jul 6 20:33:41 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l' ***all my modifications are gone*** ***changed editcron script to use /ffp/bin/crontab*** ***run my script to load cron jobs*** Wed Jul 6 20:40:20 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l' Wed Jul 6 20:40:21 AEST 2011 crontab is called from /ffp/bin/ with the the following '/mnt/usb/crontab.txt' Wed Jul 6 20:40:28 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l' ***all my modifications are there*** Thu Jul 7 19:37:18 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l' ***all my modifications are gone***
That's the entire log, so doesn't look like anything else is calling crontab in any way or form - at least not directly.
Any ideas?
Offline
You could have a look at:
/var/spool/cron/crontabs
There's probably a file in there named root that contains root's crontab. You can examine the last modified time and that might tell you when, at least, it was modified.
I suppose that there is a slight chance that something in the new firmware might be changing this file directly, instead of via crontab.
Also check to see if you are running two crond processes; perhaps one from ffp and one from the stock firmware. I don't know how bad it is to run both, but I can't see it as being a good idea. I'd disable one, at least for troubleshooting.
Pilotmm on DNS-323 FW 1.09 says the problem went away? Cliaz, did this start happening for you after a FW upgrade? What changed to make this start happening?
Offline
So just a follow-up it has been about 11 days now and there is no evidence that my crontab entries are disappearing. Furthermore there does not seem to be any evidence that anything is calling crontab other than me. My /var/spool/cron/crontabs/root file modification times indicate I was the last one to alter it (as expected). I am sorry but this problem is not repeatable enough to offer much help.
I will mention that I noticed the problem soon after I rebuilt my NAS (ie reformat drives, restore factory settings, upgrade FW, fresh install of FFP). At this point I suspect that the problem occurred because the FW installation, a restart or something else was not completely finished its initial set-up when I submitted my custom crontab file. I believe it was this initial set-up that eventually overwrote my custom crontab. Again this is speculation... however if it is true then I would recommend upgrading your FW.
Even more drastic you could do a rebuild. What prompted me to do mine was an annoying bug where I couldn't get ssh to do password-less login. Despite the fact I have set this up on many other *nix based machines. It seemed I was alone as there was a lot of evidence on the forums of others successfully setting this up on their own DNS-323. I concluded that there was an error/bug in the set-up. I mention that as evidence that the FW install or FFP install does not always work perfectly every time.
Offline
/var/spool/cron/crontabs has a file called root which seems to store the cron jobs.
Interestingly enough, it was last edited today at midday - with no correlating calls to /ffp/bin/crontab or /bin/crontab
When I used 'crontab -e' to simply open and save the cron jobs, a file called cron.update was created in the /var/spool/cron/crontabs folder, updated the root, then removed.
End result - root's modified time went to now, as expected.
There's only one crond running, so no love there =/
No firmware upgrade - rather, a hard disk crash prompted a reinstall of FFP and the rest. There IS a new firmware out, so I'm going to try that out tonight - otherwise, only thing left is a rebuild I think.
I'll keep ya informed, cheers for all your help!
Offline
I bet you are right about it being a watchdog program. I don't have the latest firmware, so I can't look myself.
But the first place I would look is at /etc/rc.sh and see if it starts any programs that look like watchdogs. If you can get a hold of the same file from an older FW, then comparing the two might quickly expose something.
Offline
You could also look at the parent process of the newly started process. That should be the watchdog.
Offline
quick update before I duck out for the day:
Sat Jul 23 01:33:42 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l'
I check to make sure my cron jobs are still there; they are. In fact, they'd been there since I upgraded firmware, about 30 hours prior
Sat Jul 23 08:49:46 AEST 2011 crontab is called from /ffp/bin/ with the the following '-l'
This is the next entry in my modified crontab script, called by me this morning to check; sadly, crontab has reset.
Once again, root has been modified in the mean time
root@NAS:/mnt/usb/ffp/home/root# ls -la /var/spool/cron/crontabs/ drwxr-xr-x 2 root root 1024 Jul 21 20:34 . drwxr-xr-x 3 root root 1024 Dec 27 2005 .. -rw------- 1 root root 116 Jul 23 04:19 root
Dump of the /etc/rc.sh file:
root@NAS:/mnt/usb/ffp/home/root# cat /etc/rc.sh #!/bin/sh mount -o remount -w %root% / echo "** Mounting /etc/fstab" mount -a umount /proc umount /sys/crfs mount -a umount /dev/mtdblock0 ln -s /sys/crfs/script/system_init /usr/sbin/system_init # move to crfs/crfs/script/system_init system_init
I don't see the sort of watchdog process there that would affect crond (or associated files/functionality), but I'll freely admit my *nix isn't crash hot.
Offline
Looks like they've re-worked the firmware quite a bit in this version. In 1.07, rc.sh is a lot longer. You'll have to follow the trail to /usr/sbin/system_init and look at that file to look for watchdog clues. This amount of re-work suggests that they could have easily added a watchdog to reset the crontab as well.
Offline
I've never had this issue with any FW version since I bought my units. Now running 1.09. I'd suggest doing a comparison of processes 'ps -ef' to see what is active in yours compared to others.
Here is my listing:
/ # ps -ef
PID USER COMMAND
1 root init
2 root [ksoftirqd/0]
3 root [events/0]
4 root [khelper]
5 root [kthread]
11 root [kblockd/0]
14 root [khubd]
52 root [aio/0]
189 root [scsi_eh_0]
51 root [kswapd0]
190 root [scsi_eh_1]
200 root [mtdblockd]
217 root [kcryptd/0]
218 root [kmirrord/0]
231 root [loop0]
1287 root xmldb -n config
1343 root [kjournald]
1530 root [kjournald]
1605 root chkbutton
1659 root fancontrol 1
1679 root op_server 3 3 3
1685 root -sh
1753 root atd
1813 root mserver
1814 root apkg
1910 root [scsi_eh_2]
1911 root [usb-storage]
2053 root /ffp/sbin/telnetd -l /ffp/bin/sh
2115 root /web/webs
2123 root crond
5806 root /usr/sbin/samba/smbd -D
5812 root /usr/sbin/samba/smbd -D
5816 root /usr/sbin/samba/nmbd -D
9640 root [pdflush]
9696 root [pdflush]
17208 root /ffp/sbin/lighttpd -f /ffp/etc/lighttpd.conf
32638 root /ffp/bin/rsync --daemon --config=/ffp/etc/rsyncd.conf
19596 root /ffp/bin/sh
19597 root ps -ef
/ #Offline
I looked at /usr/sbin/system_init and to be frank, at first it was too massive to even know where to begin (beyond the beginning, har har har...)
In any case, came back today to have second crack at it and lo n behold, my cron jobs are there.. it seems as though the firmware update + a do_reboot fixed the issue I was having.
Kind of annoying to be honest because I can't pinpoint exactly what I did to fix the issue.
- Firmware upgrade + restart (through the GUI, as per firmware upgrade functionality) = didn't work
- random reboot (first since firmware upgrade) = working, and has been for 8 days or so
In any case, here is the ps -ef dump
root@NAS:/mnt/usb/ffp/home/root# ps -ef
PID USER COMMAND
1 root init
2 root [kthreadd]
3 root [ksoftirqd/0]
4 root [events/0]
5 root [khelper]
31 root [kblockd/0]
34 root [khubd]
50 root [pdflush]
51 root [pdflush]
52 root [kswapd0]
53 root [aio/0]
192 root [scsi_eh_0]
193 root [scsi_eh_1]
194 root [scsi_eh_2]
195 root [scsi_eh_3]
212 root [mtdblockd]
254 root [loop0]
854 root [kjournald]
894 root [kjournald]
934 root [kjournald]
974 root [kjournald]
1033 root [kjournald]
1090 root [kjournald]
1147 root [kjournald]
1204 root [kjournald]
1230 root chkbutton
1232 root op_server 3 3 3
1247 root xmldb -n config
1253 root fancontrol
1300 root -/bin/sh
1312 root crond
1370 root atd
1396 root lpd Waiting
1406 root inotify_upnp
1419 root /usr/sbin/samba/smbd -D
1431 root /usr/sbin/samba/nmbd -D
1433 root /usr/sbin/samba/smbd -D
1467 root /sys/custom/upnp/upnp 0 D-Link Corporation http://www.dlink.com
1482 root mserver
1485 root apkg
1705 root [scsi_eh_4]
1706 root [usb-storage]
1844 root /ffp/sbin/syslogd
1854 root /ffp/sbin/klogd -c 3
1857 nobody /ffp/bin/transmission-daemon -f -g /mnt/HD_a2/.transmission-daem
1870 nobody /ffp/bin/transmission-daemon -f -g /mnt/HD_a2/.transmission-daem
1871 nobody /ffp/bin/transmission-daemon -f -g /mnt/HD_a2/.transmission-daem
1874 root /ffp/sbin/sshd
1875 nobody /ffp/bin/transmission-daemon -f -g /mnt/HD_a2/.transmission-daem
1887 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
1888 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
1889 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
1896 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
1898 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
1912 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
1913 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
20656 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
20661 root sh -c UpdateDB -d UPnP -a del -p /mnt/HD_a2/Torrents/Seinfeld\ 7
20662 root UpdateDB -d UPnP -a del -p /mnt/HD_a2/Torrents/Seinfeld 720p HDT
20735 root /ffp/bin/mediatomb -d --interface egiga0 --home /ffp/var --cfgdi
20895 root sshd: root@pts/0
20899 root -sh
20908 root ps -ef
24657 root [sh]Offline
Perhaps the firmware upgrade process leaves something in place to reset the cron jobs to something it expects and then the second reboot after the upgrade happens to clean it up. I don't know; it would be hard to tell without digging into the actual code more. It is possible that the tracks have been covered.
Not too many people are saying that they have the issue, so perhaps it is simply a short-lived side-effect of the FW upgrade process.
Offline
Pages: 1