How to Get a Cron Like Scheduler in Python

How do I get a Cron like scheduler in Python?

If you're looking for something lightweight checkout schedule:

import schedule
import time

def job():
    print("I'm working...")

schedule.every(10).minutes.do(job)
schedule.every().hour.do(job)
schedule.every().day.at("10:30").do(job)

while 1:
    schedule.run_pending()
    time.sleep(1)

Disclosure: I'm the author of that library.

Schedule the execution of a Python function

So, in the end, my solution was to use python-crontab as below:

python_exec_command = 'python ' + __file__ + ' ' + playlist_id + ' ' + username
    python_folder = str(Path(__file__).resolve().parent.parent) + '/venv/bin/'
    command = 'source ' + python_folder + 'activate && ' + python_exec_command + ' && deactivate'
    cron = CronTab(user='nicola')
    job = cron.new(command=command, comment=playlist_id)
    job.minute.on(minute)
    job.hour.on(hour)
    job.month.on(month)
    job.day.on(day)
    cron.write()

which will launch the following script

def main(playlist_id, username):
    # run the actual update
    cron = CronTab(user='nicola')
    cron.remove_all(command=playlist_id)
    cron.write()
    pass


if __name__ == "__main__":
    playlist_id = sys.argv[1]
    username = sys.argv[2]
    main(playlist_id, username)

so in this way I'm able to use parameters and delete the cron once executed checking for the unique id as a comment

Scheduling a cron job in python to run a python script every day at 10 am through APSCHEDULER

A slightly modified version of your code is working for me (I adjusted the cron entry so I wouldn't have to wait a week to see the results, and I made the function name argument match):

#!/usr/bin/env python3
from apscheduler.schedulers.blocking import BlockingScheduler

def cron_process():
    print ('periodic print')

scheduler = BlockingScheduler()
scheduler.add_job(cron_process, 'cron', day_of_week = 'mon', hour='*', minute='*')
scheduler.start()

How to schedule code execution in Python?

There are some ways to do this , but the best way is using 'schedule' package, i guess

However, in the first step install the package :

pip install schedule

And then use it in your code like the following codes :

import schedule

schedule.every().day.at("10:00").do(yourFunctionToDo,'It is 10:00')

cron like scheduling with python-telegram-bot

Seems like you're providing the keyword arguments the wrong way. According to the documentation link you included, the keyword arguments should be passed to job_kwargs.

Like this:

context.job_queue.run_custom(
    my_funct,
    job_kwargs={
        'trigger': 'cron',
        'days': 'mon-fri,sun',
        'hour': '11,15,19,23',
        'minute': 55,
    },
)

Crontab vs Schedule jobs in python?

In 2013 - when this question was created - there were not as many workflow/scheduler management tools freely available on the market as they are today.

So, writing this answer in 2021, I would suggest using Crontab as long as you have only few scripts on very few machines.

With a growing collection of scripts, the need for better monitoring/logging or pipelining you should consider using a dedicated tool for that ( like Airflow, N8N, Luigi ... )

cron-like recurring task scheduler design

There's 2 designs, basically.

One runs regularly and compares the current time to the scheduling spec (i.e. "Does this run now?"), and executes those that qualify.

The other technique takes the current scheduling spec and finds the NEXT time that the item should fire. Then, it compares the current time to all of those items who's "next time" is less than "current time", and fires those. Then, when an item is complete, it is rescheduled for the new "next time".

The first technique can not handle "missed" items, the second technique can only handle those items that were previously scheduled.

Specifically consider you you have a schedule that runs once every hour, at the top of the hour.

So, say, 1pm, 2pm, 3pm, 4pm.

At 1:30pm, the run task is down and not executing any processes. It does not start again until 3:20pm.

Using the first technique, the scheduler will have fired the 1pm task, but not fired the 2pm, and 3pm tasks, as it was not running when those times passed. The next job to run will be the 4pm job, at, well, 4pm.

Using the second technique, the scheduler will have fired the 1pm task, and scheduled the next task at 2pm. Since the system was down, the 2pm task did not run, nor did the 3pm task. But when the system restarted at 3:20, it saw that it "missed" the 2pm task, and fired it off at 3:20, and then scheduled it again for 4pm.

Each technique has it's ups and downs. With the first technique, you miss jobs. With the second technique you can still miss jobs, but it can "catch up" (to a point), but it may also run a job "at the wrong time" (maybe it's supposed to run at the top of the hour for a reason).

A benefit of the second technique is that if you reschedule at the END of the executing job, you don't have to worry about a cascading job problem.

Consider that you have a job that runs every minute. With the first technique, the job gets fired each minute. However, typically, if the job is not FINISHED within it's minute, then you can potentially have 2 jobs running (one late in the process, the other starting up). This can be a problem if the job is not designed to run more than once simultaneously. And it can exacerbate (if there's a real problem, after 10 minutes you have 10 jobs all fighting each other).

With the second technique, if you schedule at the end of the job, then if a job happens to run just over a minute, then you'll "skip" a minute" and start up the following minute rather than run on top of itself. So, you can have a job scheduled for every minute actually run at 1:01pm, 1:03pm, 1:05pm, etc.

Depending on your job design, either of these can be "good" or "bad". There's no right answer here.

Finally, implementing the first technique is really, quite trivial compared to implementing the second. The code to determine if a cron string (say) matches a given time is simple compared to deriving what time a cron string will be valid NEXT. I know, and I have a couple hundred lines of code to prove it. It's not pretty.

---

Related Topics