RuntimeError: cannot schedule new futures after interpreter shutdown

Question

I'm programming a python robot in the telegram, but I have an error that is not resolved, the error is in the schedule

Traceback (most recent call last):
  File "C:\Users\vini6\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\apscheduler\schedulers\base.py", line 979, in _process_jobs
    executor.submit_job(job, run_times)
  File "C:\Users\vini6\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\apscheduler\executors\base.py", line 71, in submit_job
    self._do_submit_job(job, run_times)
  File "C:\Users\vini6\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\apscheduler\executors\pool.py", line 28, in _do_submit_job
    f = self._pool.submit(run_job, job, job._jobstore_alias, run_times, self._logger.name)
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2544.0_x64__qbz5n2kfra8p0\lib\concurrent\futures\thread.py", line 169, in submit
    raise RuntimeError('cannot schedule new futures after '
RuntimeError: cannot schedule new futures after interpreter shutdown

Lizliza

Are you using python-telegram-bot? – Indulgent

See #67420300 – Pinpoint

Answer 1

In case you are using python-telegram-bot, you might be missing an updater.idle() call after updater.start_polling()

I reported a bug here, and got this solution as a reply, which fixed it for me. I had the very same error message, although it is a different package here. So leaving this for folks that come here, after searching for the above error message.

Indulgent

What about pyrogram? – Facilitation

FOR PYROGRAM: my solution was to add bot.start() (where bot = Client(...) and then use bot without with bot:. Added this before all other code and solved problem for me. Pyrogram has pyrogram.idle() and maybe it's better than leaving bot active like that, but it's up to you, i have not tested idle(), so check docs on that one – Frieze

Answer 2

It's bug or something of python 3.9.9. I also came across this issue. But it works well on python 3.7 and python 3.8. Not sure if any other python3.9.x works

Update on 2022/02/11, this issue exists from python3.9 to python 3.10

Antecedence

Interesting, I am also encountering same exception on python 3.9 – Kirst

@anarchist912 But I am not using python-telegram-bot. If it is not a bug, then python clearly modified some low-level stuffs so the original method doesn't work anymore. – Antecedence

@anarchist912, I am also not using python-telegram-bot. But I am using python "schedule" package in conjunction with "asyncio". It does look like a bug with asyncio: ittutorialpoint.com/… – Inane

same here... python 3.9 – Hip

Same here with python 3.10 – Presumption

Anyone still face the same problems ? did apschduler solved it – Hip

Answer 3

Well, i have faced the same issue as of 28-Jun-2022 and landed here while searching. After some trial and error i have found some work around which works for me as of now.

Solution 1 (trick)

What we need is to stop the program to exit. So adding some pause at the end worked for me. Here the example is with BackgroundScheduler but any Non-blocking Scheduler will have same approach.

import pause
from apscheduler.schedulers.background import BackgroundScheduler

scheduler = BackgroundScheduler()

# your code goes here

# start scheduler
scheduler.start()

# add pause in main
pause.days(1) # or it can anything as per your need

Solution 2

Use BlockingScheduler instead of BackgroundScheduler

from apscheduler.schedulers.blocking import BlockingScheduler

scheduler = BlockingScheduler()

# your code goes here

scheduler.start()

Retrorse

Solution 2 works for me. I check python version in the script and import relative scheduler. – Hip

Answer 4

You may face this issue if your code ends without a blocking loop. For instance, inside you main.py:

# code start
my_function_submitting_tasks_without_waiting()
# end of file

Instead you can do something like that

# code start
my_function_submitting_tasks_without_waiting()
while True:
  pass
# end of file

But of course instead of "while True", you could use a "while not self._signal_stop:" inside your main class

Strigose

Add a time.sleep statement inside the loop, or else you will use 100% of available idle CPU resources, wasting energy and computation. – Diffract

Answer 5

Faced the same problem while shutting down the scheduler, .shutdown(wait=False) worked fine.

c = 0
def tick():
    global c
    print(c)
    print('Tick! The time is: %s' %
          datetime.now().strftime("%Y-%m-%d %H:%M:%S"))
    # sleep(5)
    print('After sleep! The time is: %s' %
          datetime.now().strftime("%Y-%m-%d %H:%M:%S"))
    c += 1
    if c == 3:
        # sched.remove_job('my_job_id')
        sched.shutdown(wait=False)


def main():
    sched.add_job(tick, 'interval', seconds=1,
                  next_run_time=datetime.now(),  # start immediately
                  id='my_job_id')
    sched.print_jobs()
    sched.start()

Wistrup

Answer 6

As the other answers have suggested, it may be because you do not have a blocking loop at the end of your entrypoint function where you start your threads. See the following snippet for some guidance. I handle KeyboardInterrupt and SystemExit here, as well.

try:
    # Keep the main program running (or do other work)
    while True:
        time.sleep(1)
except (KeyboardInterrupt, SystemExit):
    # Optionally do cleanup or handle program exit
    pass

Hypothetically, if you needed to trigger the remote tear-down of your threads with this snippet your could use a threading.Event object, but that is a bit out-of-scope for what you're asking (but would be best practice).

Blaineblainey