How can I run a command once at launch?

[Francis Windram]

Hi All,

Seems like a simple question here but I am struggling with finding an elegant solution.

I have a scheduler running with one task that runs at around 2200 every night, then queues the next run at 2200 the next day. However I am at a loss on how to trigger off the first run (aside from a one-off script to schedule the first run)

Adding a piece of code in the model which checks whether an eod_run job is in the scheduler table and schedules one if not seems like it adds a lot of overhead, considering the models are run very regularly.

Assuming that all things work properly, once the scheduler runs one job, it should just queue the next one, but I'm not sure if that persists over server shutdowns.

Do you have any suggestions? I could drop down and use a cron job on the server itself, or using the cron functionality in web2py, but that feels like stepping backwards when we have a perfectly functional scheduler already enabled.

Thanks!

[Dave S]

Have a controller function that runs once (basically a script) /  You can put this in your startup files if you want.  (My server is restarted by hand more often than by reboot, so I haven't bothered with the startup part; I'm still editing modules used by the scheduler fairly often).

See

<URL:http://web2py.com/books/default/chapter/29/13/deployment-recipes#Start-the-scheduler-as-a-Linux-service-upstart->

and

'<http://web2py.com/books/default/chapter/29/13/deployment-recipes#Initial-Queuing-of-a-Repeating-Task>

/dps

[Dave S]

On Monday, September 2, 2019 at 8:23:57 AM UTC-7, Francis Windram wrote:

Hi All,

Seems like a simple question here but I am struggling with finding an elegant solution.

I have a scheduler running with one task that runs at around 2200 every night, then queues the next run at 2200 the next day.

Why are you queuing the next run from the current run?   Why not queue once with infinite repeats at a period of 86400 seconds, or use the crontab-like queuing option?

One good reason for doing "chain queuing" was if you were using a resource that expires, but even that should be okay with the other options.

/dps

 

[Francis Windram]

Wonderful, thanks Dave! This is probably the correct approach for me to take.

And that is a fair point, I think for the most part I organised it like that to prevent drift (though I do know of the preventdrift argument to schedule_task()) and ensure that the task always queued for 2200 the next day.

That said, looking at the problem with fresh eyes it does seem to be a simpler and more sensible option just to use the built-in rescheduling function.