Custom cron job - how?

Discussion in 'Sveasoft Firmware' started by Gedikas, Jun 16, 2005.

  1. Gedikas

    Gedikas Network Guru Member


    I'am using WRT54G (v2.2) with Firmware Version: Alchemy-V1.0 v3.37.6.8sv

    How to create custom cron job?
    Im logging in via telnet.

    I create in /etc/cron.d my crond job file:
    echo "*/30 * * * * root /sbin.." > /etc/cron.d/myjob

    That is all ok - cat myjob shows content of myjob.

    How to save mayjob to be available after reboot?
  2. tbblitz

    tbblitz Network Guru Member

    i dont think u can, im having the same problem with the iptables, when it restarts i loose it
  3. malfeasance

    malfeasance Network Guru Member

    Yes You Can!

    You CAN do this; I'm running out the door so I can't show you what I did last night to make it work.

    Search on cron and reboot and iptables. I will report my experience when I get time later.
  4. davidsonf

    davidsonf Network Guru Member

    Here's one way to have files survive a reboot. It has the advantage of working on any of the third party firmware versions that has any kind of a startup file. (Another way is to mount a jffs filesystem, but that isn't implemented everywhere.)

    Note that /etc/cron.d is a symbolic link to /tmp/cron.d, so you can simply cd to /tmp and work with it there. The trick is to pick a symbol name, and save the file to nvram using that name. This can be done with any file, and this example will just happen to save the cron.d file.

    First make sure that whatever symbol name you use in nvram is not already being used. I'm going to use "crond", so this will check for that string anywhere in nvram,

        nvram show | grep crond
    Nothing at all came up, so it's not being used. This command will save the /tmp/cron.d file to nvram using the symbol name "crond",

        nvram set crond="$(cat /tmp/cron.d)"
        nvram commit
    You can check to see if your file is really there,

        nvram get crond
    That should show you the contents of your file. Then you need to use that command, in /tmp/.rc_startup, to cause it to be dumped to /tmp/cron.d when the system boots and runs the startup file. So edit /tmp/.rc_startup, and put this command in it,

        nvram get crond > /tmp/cron.d
    Of course, then you have to also save the contents of the startup file to nvram, so do this:

        nvram set rc_startup="$(cat /tmp/.rc_startup)"
         nvram commit

    And now at boot time, your /etc/cron.d will magically be recreated.
  5. malfeasance

    malfeasance Network Guru Member

    Thank you davidsonf for your post. It really cleared up some stuff for me, like , how to create a rc_startup file in the first place. It's a "hidden" or . file! But, it doesn't exist by default, you have to make it. And, how to update the rc_startup variable. In all of my searching, I hadn't yet discovered these things. (Maybe I missed them.)


    Now, in your example, you use the terms "crond file" and "cron.d file." You also mention "recreating the cron.d at each bootup" and "nvram set crond="$(cat /tmp/cron.d)" and "nvram get crond > /tmp/cron.d"

    cron.d is actually a directory, not a file! So, some of your examples are confusing. I guess choosing this directory and this file name, crond, as your examples has perhaps unnecessarily confused things - can't cat a directory anyway.

    If I'm missing something, please point it out!

    However, there are crontab files already in existence and being used in /tmp! There is /tmp/crontab! Why not use it, which is what I've done. It already sets an environment variable, PATH=, (I am using Alchemy 1.0 and DD-WRT Pre. 4, so perhaps that is relevant to these firmwares.) I have included this in .rc_startup:

    /bin/sleep 20
    /bin/echo '0 4 */2 * * root /sbin/reboot' >> /tmp/crontab

    to reboot a router at 4:00am every other day. I know this is sloppy; better to have the contents of a file cat-ed from, like in your example, rather than entering this directly into .rc_startup.

    Also, the same techniques could be used to perhaps place crontabs in the /tmp/cron.d directory. There is one in there now: check_ps

    Also, /tmp/var/spool/cron/crontabs/root exists in Alchemy and DD-WRT (maybe all of them) by default, and could be used to execute cron commands. It' currently empty, but cron will look there, according to man cron, to run commands or set environment variables!

    Feel free to point out my errors and thanks again for your post! I'm finally "cronning!" I'm no longer a "cron" virgin! (Would sound strange to the non-geek - or even to them, perhaps. The Good Doctor said the absurd; so will I!)
  6. davidsonf

    davidsonf Network Guru Member

    Well, considering the basic errors in what I wrote, I'm certainly glad that you were able to pick out the essence of it! Sorry about the confusing parts! My errors, not yours.

    Not enough sleep or not enough coffee! Grrrr...

    I wasn't going by specifics, and should have been! (I haven't actually set up a cron job on a wrt54g, but do it very commonly on other Linux boxes.) I forgot to look and see just exactly what is on the wrt54g, because there are significant variations in how cron works from system to system.

    What you are missing... is merely what I Ieft out!

    In my entire previous article, just substitute 'crontab' for each and every instance of either "cron.d" and "crond", and then it might make more sense!

    Excellent! I imagine that sleep is there due to observed behavior??? I don't remember just off hand when the ~/.rc_startup file is executed in relation to when the /tmp filesystem is populated, but the sleep would make sure that
    /tmp/crontab has already been created.

    That looks just fine to me. No real need to waste extra space in the nvram for something that short and sweet.

    Yes. These are all more or less redundant on an embedded system with only one user who is always root.

    I don't see any. You've got it pegged.
  7. Gedikas

    Gedikas Network Guru Member


    Thank you both guys! That's what i need.
  8. malfeasance

    malfeasance Network Guru Member

    Oh Boy!


    You bet! I learned as much as you.


    Thanks for the kudos! You got me over the top.

    As far as the sleep command: it is commonly used in script files for these WRT's, I've noticed, so I included it just in case.

    However, yes, there is a lot of activity happening during boot and for a good 30 seconds. Even running a Site Survey has to turn off the AP, scan, then turn it back on. Then it's like a partial reboot. I see some of the rebooting process through WallWatcher. Plus, it's become known that one has to 0 the AP to SS.

    I would love to do one of those serial port hacks and setup a console just to really see whazz a happenin' when it'za happenin'.

    Again guys, Thanks! =D> =D>
  9. davidsonf

    davidsonf Network Guru Member

    Re: Oh Boy!

    In the beginning, the init code was small because Broadcom and Linksys avoided using the more complex UNIX SysV init code. But the init code has grown (in third party firmware), and should be converted to something which can deal with the complexity better. Instead of redoing it, most third parties are just adding to it, and it is a mess.

    It doesn't reboot, but "wl ap 0" changes the wireless to client mode, a scan is done, and then "wl ap 1" re-enables access point mode. And then... all of the associated clients have to re-establish a connection...

    I've got the hardware (and for a JTAG connection too), and will someday get around to putting it into a wrt54g.

    However... in the mean time you can see the same stuff by telneting in, and from the command line doing "dmesg | more", which displays the kernel's circular log buffer.

    One trick is to put something like "dmesg > /tmp/bootlog" into the /tmp/.rc_startup file. That saves the buffer as it exists when the startup file is run. You won't lose anything in the circular buffer by having it overwritten by later log messages.

    Also, I haven't tried to do it, but it should be possible to configure the log system to save all boot time messages. I'm not sure how effective that is, but between dmesg and the logs, it is possible to see everything that a console will show.

    The real advantage of the console is that you can reconfigure the ethernet bridge, vlan's, ports, etc. and a mistake won't require a reboot or debrick operation to get access again.

    I don't know enough yet about just what the JTAG link can do. So far all I've seen is software for a very slow file transfer to the nvram. It should also be able to do low level debugging, but I don't see a lot of value in that. I've gotta do some research and learn more about it.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice