latenitetech
Regular Contributor
One of my recent projects has been migrating my (old) X10-based home automation solution from a Windows PC (running 'Active Home Vista') to my Asus router (using the Linux program 'heyu'), partly so I can realize electricity savings by not having to run that PC 24x7 (while the router is always on anyway), and also just as an interesting hobby project.
The heyu implementation makes use of cron for scheduling/running local events (all via the 'cru' command in heyu scripts), and I was looking for an easy way to make such events persistent across reboots. Looking around this forum and the web in general, there are lots of posts about just rebuilding crontab on reboot with individual 'cru' entries in init-start, or keep a crontab mirror in jffs, then copy it over to /var/spool/cron/crontabs in init-start. So I considered similar solutions, but those methods are a bit of a pain to keep track of and restore dynamic 'cru' activity.
But then it occurred to me, "Why not just put the actual crontab file in /jffs with a link?" Then whatever changes get made to it on the fly (e.g. via 'cru') would always still be there on reboot. No need to have "rebuild" commands on startup, or keep a mirror. I did some googling on this kind of persistent solution and didn't find much, although admittedly my searching wasn't exhaustive. My apologies if this has already been proposed and discussed previously.
It's actually quite trivial to implement with just a link command added to init-start:
Obviously you need to do a one-time setup of creating /jffs/crontabs, and then copying over the current crontab file (/var/spool/cron/crontabs/admin) to that new directory. To test it first without rebooting, it's best to first stop crond (service stop_crond), then create the link above, then restart crond (service start_crond). Cron should work as expected, and then on reboot as well, with all your previously scheduled jobs just as they were prior to reboot. Of course, if you already have a reboot recovery solution in place (e.g. rebuild cru entries, or a copy mirror), you'd want to disable them.
I've been running with it this way for about a month now, rebooted numerous times, and upgraded fw to 380.65 and it all seems to work fine. Anyone see any fatal flaw in this approach? I know there is always a concern of excessive writing of jffs, but my 'heyu' crontab updates are typically less than a dozen a week, so I don't think that would be considered excessive.
Anyway, just sharing it here for feedback and/or if someone else finds this approach interesting or useful.
The heyu implementation makes use of cron for scheduling/running local events (all via the 'cru' command in heyu scripts), and I was looking for an easy way to make such events persistent across reboots. Looking around this forum and the web in general, there are lots of posts about just rebuilding crontab on reboot with individual 'cru' entries in init-start, or keep a crontab mirror in jffs, then copy it over to /var/spool/cron/crontabs in init-start. So I considered similar solutions, but those methods are a bit of a pain to keep track of and restore dynamic 'cru' activity.
But then it occurred to me, "Why not just put the actual crontab file in /jffs with a link?" Then whatever changes get made to it on the fly (e.g. via 'cru') would always still be there on reboot. No need to have "rebuild" commands on startup, or keep a mirror. I did some googling on this kind of persistent solution and didn't find much, although admittedly my searching wasn't exhaustive. My apologies if this has already been proposed and discussed previously.
It's actually quite trivial to implement with just a link command added to init-start:
Code:
#first remove firmware-created empty directory prior to link creation
rmdir /tmp/var/spool/cron/crontabs
ln -ns /jffs/crontabs /tmp/var/spool/cron/crontabsObviously you need to do a one-time setup of creating /jffs/crontabs, and then copying over the current crontab file (/var/spool/cron/crontabs/admin) to that new directory. To test it first without rebooting, it's best to first stop crond (service stop_crond), then create the link above, then restart crond (service start_crond). Cron should work as expected, and then on reboot as well, with all your previously scheduled jobs just as they were prior to reboot. Of course, if you already have a reboot recovery solution in place (e.g. rebuild cru entries, or a copy mirror), you'd want to disable them.
I've been running with it this way for about a month now, rebooted numerous times, and upgraded fw to 380.65 and it all seems to work fine. Anyone see any fatal flaw in this approach? I know there is always a concern of excessive writing of jffs, but my 'heyu' crontab updates are typically less than a dozen a week, so I don't think that would be considered excessive.
Anyway, just sharing it here for feedback and/or if someone else finds this approach interesting or useful.
