At jobs: how to survive a reboot?

Hello,

I fired up some at jobs, but after a power loss they were gone. How can I make at jobs survive a reboot? I don't want to create and delete cronjobs for one-shot events all the time. On Linux I am used to at jobs being persistent.

:confused:

  • The at command isn't installed by default
  • Since OpenWrt doesn't save states like this upon reboot...you'll have to save this command somewhere that survives a reboot

Given that's the case (you might not like it):

  • place the at and command in /etc/rc.local
  • or place the scheduled command in /etc/crontabs/root
1 Like

The best way is to make your application a true service by writing an init script for it in /etc/rc.d. Once set up it will not only start on boot but also re-start if it crashes.

2 Likes

Don't get angry at me, but that is not the use of "at" jobs, that they are supposed to have: a one-time job that is scheduled by the use of the "at" command on the command line should not have the necessity of being written down as a cronjob, that remains inside the user's crontable forever, if it is not removed afterwards.

not rebooting much...

1 Like

When was the last time that you were using "at" on a Linux machine? Jobs scheduled with "at" have been persistent to reboot for ages in Linux.

check the init.d script and hardlink to persistent storage... a typical router does not have storage to burn nor cmos+battery...

your comparing an apple to orange juice...

        [ -d /var/spool/cron/atjobs ] || {
                mkdir -m 0755 -p /var/spool/cron/atjobs
                touch /var/spool/cron/atjobs/.SEQ
                chown -R nobody:nogroup /var/spool/cron/atjobs
        [ -d /var/spool/cron/atspool ] || {
                mkdir -m 0755 -p /var/spool/cron/atspool
                chown -R nobody:nogroup /var/spool/cron/atspool

var is in ram... hardlink it else wear ... your welcome...

That is an explanation I can understand and that is welcome. But simply assuming I didn't know about "at" and rebooting Linux, sounded a bit snobbish to me. :frowning:

After all... is there any really imortant reason why "at" jobs should not be written to persistent memory, in contrast to "cron" jobs? I understand that memory shortage is a big issue on routers, but "at" jobs don't really need much memory. And apart from being used for one-time jobs, "at" is used to schedule events just like "cron", and just like "cron" it is possible that a scheduled job is due after a power down. So it would be wise not to forget this job after restarting the router.

1 Like

It is just unfortunate that the atjobs are located in var, which in OpenWrt is symlinked to tmp, which is stored in ram.
Cronjobs are in etc which is located on the flash.

1 Like

I guess the OP doesn't wanna understand that. Perhaps the OP should install a distro were the at command properties are saved to a persistent location; then the process would work as they expect.

The OP could also re-code and recompile - so it works in that manner.

Correct; also OpenWrt is a distro for use as a router. You can also use an Uninterruptible Power Supply, then your router doesn't reboot and hence your at command continues to work as expected.

But honestly:

  • I'd suggest a re-code of your router if this at thing is truly a concern for you
  • :bulb: Lastly, perhaps you can just symlink to a location that is in fact persistent (I do this all the time with other packages running on OpenWrt to make: settings/session keys/dynamically updated files/etc. persistent across reboots). There's only one catch, the the user of the program isn't root, you'll have to cleanup the permissions if/when you sysupgrade. :wink:

@lleachii:
There's no need for you to speculate about my level of understanding. I understand very well that "at" jobs are stored in RAM, and I am just wondering why they are not stored in flash memory, just like "cron" jobs.

But since you asked for it, I can give you an example why storing "at" jobs in RAM could also be a sort of security issue: imagine you log into a remote (~100km) router, and set a route or you activate a special wifi network that a colleague needs at the spot for just a short time. You fire up an "at" job, that will bring this network down or delete this route in a few minutes, and you rely on that job. Before the "at" job is run, the power fails. The router comes back to life, and has forgotten that there's a network that needs to be shut down.

Since you are so much better in understanding than I am, there's no need to explain what kind of problem such a situation could bring.

Because this means they are "saved to disk." I thought you noted you didn't want that?

I guess that's only an issue when someone suggests cron. Nonetheless, did you see what I suggested?

Will this solve your problem?

I didn't ask; but I honestly don't see that as a security issue...also, I don't see how it's an issue with storing. I see that as an issue because of NOT storing the at commands to a persistent location...hence my suggestion to make a symlink to a location that is persistent (you kinda ignored the recommendation, though)...

...then again, I'm aware (and accept) that those settings are not persistent on vanilla OpenWrt.

I never said that I did not consider your recommendation. Where did you get that impression?

Again: I was asking why "at" jobs are treated not the same way as "cron" jobs are treated, why "at" jobs are stored in memory only. If there was an important technical reason for this, I'd like to know this reason, so that I will know why my router will melt down, or why it will mate with the neighbor's cat or go out for lunch. That's all.

And if you can't see a security issue with scheduled tasks not being done as they were supposed to be, because a power down deleted the schedule, then I suggest you think about it again.

Your best bet is to raise this with the maintainer, preferably with a ticket, rather than in this forum.

2 Likes

In which OpenWRT package provides the "at" command ?

1 Like