Crontab
27 February, 2012 - 12:17
I don't know if anyone else has had this problem, but a couple of times recently my crontab file has just disappered. It was working OK at 7 am today but when I went in to edit it at 8 am the whole file had vanished.
I'll keep an eye out and report any further occurrences.
Allan
27 February, 2012 - 15:42
#2
Not sure if this is related ...
http://lists.busybox.net/pipermail/busybox-cvs/2010-November/031927.html
I tend to use the google calendar for the scheduled things.
Derek.
27 February, 2012 - 16:18
#3
How are you editting this file
Are you using 'crontab -e' or are you opening the file directly with VI and hacking away? This could be important, as it might be that 'crontab -e' places locks and other things in place to prevent this issue.
Derek using google isn't a workaround as it can't provide the flexibility and control that cron can.
Brett
27 February, 2012 - 17:46
#4
To clarify
OK to clarify my situation.
I have attempted to edit the file via crontab -e but the file is shown to be empty. I then try a crontab -l and the file again shows empty. The file ROOT is still present but apparently empty. Cron was runnin great up until I did a Crontab -e.
Copying a new ROOT file and doing "crontab root" makes everything better.
Has happened to me twice to date.
Garry
27 February, 2012 - 18:01
#5
I wonder if this is due to
I wonder if this is due to the fact that there is a symlink where the crontab file really lives pointing back to a file on /etc
Could that be causing this issue somehow? Going to be hard to unravel this one. Ok so try NOT using crontab -e and just edit the /etc/crontab file directly using vi then. Perhaps the edit command is responsible after all.
Brett
29 January, 2013 - 19:17
#7
disappearing crontab file
For the past few days I've noticed that the cron has stopped working sometimes.
If I don't use crontab -e all will be fine for a few days. So I have taken to editing a file in vi then copying over using crontab /filename
If I then try crontab -l I will get my entries listed. If I try crontab -e to edit it will work usually
Today I tried crontab -e and nothing was there.For some reason I scrolled up through the terminal window and spotted this...
# crontab -e
crontab: write error: No space left on device
As far as I know invoking crontab -e creates a temporary file for editing. Now if that file cannot be created then when closing vi (whether you save or not) the now empty temporary file will over write the original crontab and hey presto...empty file. So I am thinking that maybe, just maybe I have a few stray files that have built up over time. I'm going to backup and force a clean install and see if that helps matters. if I'm not back in an hour you'll know I'm pulling more hair out :)
29 January, 2013 - 22:51
#8
cron lives again
crontab -e seems to be ok now BUT
since I've updated I have no response from jeenodeApplet. I've set it to debug=1 and all the nodes are reaped after the TTL times out. I don't even get any of the usual RF 'noise'.
I've tried microcom -s 57600 /dev/ttyUSB0 but get no response from the basenode.
microcom -s 57600 /dev/ttyUSB1 gives me the xml from the current cost so the serial schema seems to be ok.
I can't think of what else would have changed to cause this. I was running 307.2 up until the clean update so it's not an issue with that and I'm pretty sure I restored all my other bits and bobs.
I'll try and reflash the basenode direct on my mac but other than that, anybody got any clues?
UPDATE:
Checked the base node by connecting direct to comp. All looked good, correct address etc. Re-attached to HAH and now it works.....very strange (and yes I did try several reboots, power cycles etc)
Why this would happen at the same time as an update is a mystery but happy now and so is SWMBO
:)
29 January, 2013 - 23:18
#9
Couple of thoughts on your
Couple of thoughts on your problems
a) filesystem filling up - yes this is a bit of a problem.
There are only TWO mount point that are writeable. /var which never persisted past a reboot as its RAM based, the other /mnt/jffs2/jffs2_3 will as its FLASH based. Use the (du) command to find out where all the space has gone. ALSO if you have a BAD job perhaps /var filled up with DEBUG output. WARNING: do not put debug in your plugboard scripts and just leave it enabled or your will fill up /var giving you all sort of grief. If you are applied my "save the logs" reboot script you might want to GZIP the files as they are transferred over to save some space in FLASH too. (I didn't do this).
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 13368 13368 0 100% /
tmpfs 256 20 236 8% /var
/dev/mtdblock2 640 288 352 45% /mnt/jffs2/jffs2_3
# cd /mnt/jffs2/jffs2_3
# du -sh *
46.0K etc
0 home
10.5K root
5.0K tmp
#
b) on the base node - that is indeed curious and I don't have an answer on this one.
Brett
29 January, 2013 - 23:54
#10
darn debug
I think the main culprit was that debug has been enabled in jeenodeApplet.lua for a long time, so all the reaping node messages have been stacking up. As I am usually playing with the box, the odd reboot has probably cleared stuff out but add on to that the various other log messages I have been adding and the fact the box has not been cleared for a long time. When I checked the logs that I backed up before the update the plugboard log was a mighty 233k and tmpfs (var) had 0 available, hence problems with crontab.
All debug is now off as the scripts are all running fine.
As for the basenode, like you say Brett, a mystery but now working again.
Thanks for the extra commands. I think it's time I bought a unix manual to go with my many other reference books :) SWMBO will approve after tonight ;)
16 February, 2013 - 21:35
#11
OOoooOOps
To quote britney...ooops I did it again. While trying to help AndrewJ with his roomnodes I turned debug back on in jeenodeApplet. Several days later the heating went off :)
Yep /var was full again, crontab stop working and various other bits...Lesson learned until the next time :)
Happened just yesterday to me too. Was working ok but when I went to edit my lights on time found the file didn't exist. Had to copy across my backup from my FTP Server. Garry