Ich benutze beide und sie funktionieren einwandfrei

nach dem Update auf Version 4.1.0 von Version 4.0.2 - ähnlicher Fehler, Taskplaner funktioniert nicht richtig

Das gleiche hier, wenn ich auf 4.0.2 downgrade, funktioniert es wieder.

Ich denke, dieser Fehler hängt mit der Zeitzone zusammen. Wenn ich die Zeitzone auf UTC ändere, funktioniert es.

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = Wahr

Könnten Sie sich bitte noch einmal bei der aktuellen master Filiale erkundigen?

Ich kann diesen Fehler in 4.1.0 bestätigen

in meinen Einstellungen:

CELERY_TIMEZONE = 'Europe/Moscow'

Und ja, es funktioniert gut mit:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True

Gleiches Problem – wir haben mehrere Projekte, die Sellerie-Beat verwenden, aber eines davon hat die CELERY_TIMEZONE auf die Projektzeitzone eingestellt, die Amerika/NewYork war. Ich bin buchstäblich mit 18 Millionen Nachrichten auf dem Rabbit QA-Server aufgewacht, weil die Arbeiter nicht mit der Geschwindigkeit Schritt halten konnten, in der sie in die Warteschlange gestellt werden – Hunderte pro Minute. Das Löschen der Einstellungen und das Belassen des Projekts standardmäßig auf CELERY_TIMEZONE von None haben das Problem ebenfalls behoben.

FWIW -- Ich glaube nicht, dass wir den DatabaseScheduler verwenden. Vielleicht sollte der Problemname umbenannt werden?

@matteius @AyumuKasuga Wenn Sie einen Test mit dem master Zweig ausführen können, um den Fix zu überprüfen, wäre das großartig. Entschuldigung für die Probleme.

Hallo @georgepsarakis !
Ich habe gerade Master Branch getestet und leider besteht das Problem in meinem Setup immer noch.

Hier gilt das gleiche!

Hi,

Ich habe ein ähnliches Problem. Ich habe die Setup-Anweisungen von django-celery-beat befolgt von: http://docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True
CELERY_RESULT_BACKEND = 'django-db'
CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'

Dann definiere ich eine periodische Aufgabe:

@periodic_task(run_every=timedelta(seconds=30))
def do_stuff():
   print("HI")

Beim Starten von Selleriebeat erhalte ich folgende Ausgabe:

$> DJANGO_SETTINGS_MODULE="proj.settings.dev" celery -A proj beat -l info
celery beat v4.1.0 (latentcall) is starting.
__    -    ... __   -        _
LocalTime -> 2017-08-28 15:58:44
Configuration ->
    . broker -> amqp://guest:**<strong i="14">@localhost</strong>:5672//
    . loader -> celery.loaders.app.AppLoader
    . scheduler -> django_celery_beat.schedulers.DatabaseScheduler

    . logfile -> [stderr]@%INFO
    . maxinterval -> 5.00 seconds (5s)
[2017-08-28 15:58:44,425: INFO/MainProcess] Writing entries...
[2017-08-28 15:58:45,629: INFO/MainProcess] DatabaseScheduler: Schedule changed.
[2017-08-28 15:58:45,630: INFO/MainProcess] Writing entries...

Die periodische Aufgabe ist in der Datenbank vorhanden und als enabled .

Ein Selleriearbeiter erhält jedoch keine regelmäßigen Aufgaben und führt diese nicht aus:

$> DJANGO_SETTINGS_MODULE="proj.settings.dev" celery -A proj worker -l info -E

 -------------- celery@proj-dev v4.0.2 (latentcall)
---- **** ----- 
--- * ***  * -- Linux-4.4.0-83-generic-x86_64-with-Ubuntu-16.04-xenial 2017-08-28 15:57:42
-- * - **** --- 
- ** ---------- [config]
- ** ---------- .> app:         proj:0x7f89f78faeb8
- ** ---------- .> transport:   amqp://guest:**<strong i="20">@localhost</strong>:5672//
- ** ---------- .> results:     
- *** --- * --- .> concurrency: 1 (prefork)
-- ******* ---- .> task events: ON
--- ***** ----- 
 -------------- [queues]
                .> celery           exchange=celery(direct) key=celery


[tasks]
  . proj.tasks.do_nothgin
  . proj.tasks.do_stuff

[2017-08-28 15:57:42,269: INFO/MainProcess] Connected to amqp://guest:**@127.0.0.1:5672//
[2017-08-28 15:57:42,287: INFO/MainProcess] mingle: searching for neighbors
[2017-08-28 15:57:43,324: INFO/MainProcess] mingle: all alone

Software:

celery==4.1.0
django-celery-beat==1.0.1
django-celery-results==1.0.1
Django==1.8.2

Jede Idee/Hilfe zur Lösung dieses Problems ist willkommen.

Am besten,
Sebastian

Ein Stück Scheiße. Es funktioniert nicht.

@mchen-scala Ich denke, OSS-Projekte sind für die Zusammenarbeit und objektive und konstruktive Kritiker gedacht. Wie viele Codezeilen hast du in das Stück Scheiße gesteckt? Ich habe tatsächlich Sellerie mit Beat, der perfekt funktioniert.

Ich habe weitaus fortschrittlichere Systeme gebaut, als Sie jemals haben werden. Ich habe Betriebssysteme geschrieben und Hochfrequenz-Handelsplattformen und große rechenzentrumsübergreifende DBs gebaut. Und viele mehr.

Zeilen von Code? Ich schaue mir nur Systeme an, die FUNKTIONIEREN. LOC ist für Tyros.

Ich muss Sellerie verwenden, weil das System, das ich geerbt habe, es verwendet. Ich werde es loswerden und meine eigenen schreiben, sobald wir unsere erste Lieferung abgeschlossen haben.

Zusätzlich zum Beat-Problem ist es ein GIGANTISCHER WITZ, die Leute zu bitten, eine Sperre zu verwenden, um sicherzustellen, dass die Eigenschaft bei der Aufgabenausführung höchstens einmal vorhanden ist.

Bleiben Sie bei dem, was Sie gut können, nämlich OSS, da Sie keine hochbezahlten Jobs bekommen.

@mchen-scala Sie haben noch nie in Ihrem Leben ein komplexes System geschrieben, Sie können nicht einmal den Kontext dieses Tickets verstehen, nämlich dass es in der Celery 4-Serie einige Versionen gibt, bei denen der CELERY_BEAT_SCHEDULE nicht befolgt wird, wenn die Zeitzone nicht UTC ist.

Ihre Punkte sind alle ungenau und in vielerlei Hinsicht beleidigend. Der Witz ist, dass Sie hierher kommen, um uns für die Arbeit an einem OSS-Projekt zu beleidigen, das den Bedürfnissen vieler Menschen in vielen Branchen entspricht. Ich gehe davon aus, dass alles, was Sie jemals für einen Arbeitgeber geschrieben haben, noch nie so viel Licht ins Dunkel gebracht hat wie das Celery-Projekt. Da Sie tatsächlich keine Ihrer früheren Arbeiten referenziert haben. In einer agilen Welt würdest du alle 2-4 Wochen veröffentlichen. Die Tatsache, dass du an einem Projekt arbeitest, das du geerbt hast, anstatt an diesen fantastischen Systemen, die du angeblich gebaut hast, zeigt mir nur, dass du ein überhöhtes Selbstwertgefühl hast.

Außerdem ermutige ich Sie mchen-scala, Sellerie abzuschalten - vor allem, weil wir Ihre Einstellung in unserer Community nicht brauchen. Ich habe einen hochbezahlten Job, weil ich in der Lage bin, OSS zu nutzen und bei der Behebung von Problemen zu unterstützen, wenn sie auftreten. Ich schlage vor, Sie folgen Ihrem eigenen Mantra und bleiben bei dem, worin Sie gut sind, was anscheinend darin besteht, Ihre eigenen Lösungen für Probleme mit bestehenden Lösungen zu entwickeln und für den Rest von uns ein asozialer Idiot zu sein. Cya!

Ich habe die genaue Codezeile, die meine bereits zeitzonenbewusste Datumszeit in eine zukünftige Datumszeit in einem Offset von +20 umwandelt, genau bestimmt, von dem ich sicher bin, dass es sich nicht um einen echten Zeitzonen-Offset handelt.
2017-10-11 22:42:27.041931-04:00 wird an der Zeile in meinem Pull Request in 2017-10-12 22:42:27.041931+20:00 umgewandelt.
Anscheinend bleibt das Datetime-Objekt im UTC-Modus an dieser Stelle im Code gleich. Was als nächstes passiert, ist, dass das Ergebnis von verbleibendes_delta als -1 Tag interpretiert wird, 1:27:32.958069 hinter dem Aufgabenplan. So sendet es die Aufgabe aus und schläft nicht lange, weil es immer hinterher ist. Es schlägt die Aufgaben einfach immer wieder aus, da es immer -1 Tage bis zur Fälligkeit der Aufgabe sind.

Zugegeben, mein PR kommentiert eine echte alte Codezeile, und doch schienen alle Unit-Tests bestanden zu sein und dieses Problem in meinen Tests gelöst. Auf der Suche nach dem Feedback von Mitarbeitern.

Ich habe gezeigt, dass dies sowohl bei Python 2.7 als auch bei den Versionen Python 3.5 und 3.6 ein Problem ist. Um nicht zu sagen, dass es kein Fehler in anderen Versionen ist, das sind nur diejenigen, mit denen ich Umgebungen einrichte.

Ich habe versucht, von der Nichtverwendung der Datenbank für Beat zu django-celery-beat zu migrieren ... Der Tag habe hauptsächlich Github-Probleme gelesen :(

Gibt es jemand anderen, der dies nicht zum Laufen bringt, wenn er CELERY_TIMEZONE = 'UTC' ? Ich habe auch Probleme, es mit diesem Set zum Laufen zu bringen.

@xeor Möglicherweise müssen Sie auch CELERY_ENABLE_UTC = True setzen

Das eigentliche Problem bei der Übergabe der Datumszeit an localize() besteht darin, dass, wenn Sie eine lokale, nicht UTC-Zeitzone für Ihr Projekt festgelegt haben, diese Datumszeit bereits richtig ist, wenn Sie in localize gehen, und dann dt = dt.astimezone(tz) wandelt dies in a . um unsinnige zukünftige Datetime mit einer Zeitzone, die keinen Sinn macht.

@xeor Ich hatte das gleiche Problem auch mit den folgenden Einstellungen:

CELERY_TIMEZONE = 'UTC'
CELERY_ENABLE_UTC = True
CELERY_BEAT_SCHEDULER = 'django_celery_beat.schedulers:DatabaseScheduler'

Nun, ich weiß, es klingt albern, aber ich habe sowohl Celery als auch django-celery-beat deinstalliert und sie mit ihrer neuesten Version wieder installiert und es hat funktioniert.

Danke.. Ich habe es auch mit all diesen 3 versucht, ohne Glück.
Ich werde es später mit einem sauberen Neuaufbau der Umgebung versuchen.

@xeor Nun, es ist sehr gut möglich, dass dieses Problem nicht das Problem ist, das Sie haben, obwohl es vielleicht so ist. Der Hinweis in diesem Ticket war für alle Benutzer, die dieses Problem bisher hatten, konsistent, was dazu führte, dass geplante Aufgaben außer Kontrolle geraten und Aufgaben erstellt wurden, die sich aus diesem Grund aufbauen und nicht ordnungsgemäß verarbeitet werden. Könnten Sie Ihr spezifisches Problem genauer beschreiben, da Sie anscheinend nicht viele Details zu den Fehlern oder dem unerwarteten Ergebnis hinterlassen haben, das Sie erhalten?

Immer gerne behilflich. Ich habe nur festgestellt, dass wir dieses Problem ohne den DatabaseScheduler hatten und es behoben haben, indem wir nur die Zeitzonen geändert haben. In meinen Tests habe ich gezeigt, dass die vor und nach diesem Fehler generierte Schedule-Datei identisch war, daher glaube ich nicht, dass der Fehler am Scheduler liegt, sondern eher an der Art der Datetimes, die an den localize()-Aufruf übergeben werden.

Danke für die Warnung!

Ich werde nicht in der Lage sein, eine tiefere Schleife vor vielleicht Ende nächster Woche oder der Woche danach zu machen. Ich werde mich in der Zwischenzeit in diesem Thread über den Fortschritt informieren.

Ich bin mir nicht sicher, ob mein Setup etwas Besonderes ist, aber ich verwende Docker, Amqp, Rabbitmq und die neuesten Versionen von Sellerie-Python-Paketen (nicht Rabbitmq tho). überprüfen kann)..

Ich habe ein ähnliches Problem, manchmal funktioniert Sellerie-Beat nicht (es sendet keine Aufgabe an den Broker) Außerdem sendet es alle 59 Minuten zu viele Aufgaben
Ich habe eine Testaufgabe erstellt, die jede Minute ausgeführt wird

[2017-11-09 20:52:00,052: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:53:00,049: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:54:00,019: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:55:00,027: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:56:00,049: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:57:00,004: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:58:00,045: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,032: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,035: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,037: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:00,044: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
...
[2017-11-09 20:59:59,977: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,979: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,981: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,986: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,989: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,994: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 20:59:59,997: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:00:00,000: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:01:00,047: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:02:00,047: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)
[2017-11-09 21:03:00,053: INFO/MainProcess] Scheduler: Sending due task test-task (tasks.test.test_task)

Ab Minute 59 beginnt eine Reihe von Aufgaben zu laufen und wenn die Zeit Minute 0 erreicht, läuft es wieder wie erwartet.
Ich habe keine Ahnung von diesem Fehler..?

Dies ist meine Einstellung in Sellerie 4.1.0

timezone = 'Asia/Seoul'
enable_utc = False

Ich verwende Datei-DB für den Zeitplan

Ich habe dieses Problem auch bei Python 3.6.3, Pytz 2017.3, Django 1.11.7, Sellerie 4.1.0 und Django-celery-beat 1.1.0.

Ich lösche zuerst die Datenbank:

#update django_celery_beat_periodictask set last_run_at = NULL;
#select name, last_run_at from django_celery_beat_periodictask;
           name           |          last_run_at          
--------------------------+-------------------------------
celery.backend_cleanup |                                                       

> pipenv run celery beat -A appname -l debug --scheduler django_celery_beat.schedulers:DatabaseScheduler
Loading .env environment variables…
celery beat v4.1.0 (latentcall) is starting.
__    -    ... __   -        _
LocalTime -> 2017-11-30 08:28:58
Configuration ->
    . broker -> amqp://guest:**<strong i="9">@localhost</strong>:5672//
    . loader -> celery.loaders.app.AppLoader
    . scheduler -> django_celery_beat.schedulers.DatabaseScheduler

    . logfile -> [stderr]@%DEBUG
    . maxinterval -> 5.00 seconds (5s)
[2017-11-30 08:28:58,945: DEBUG/MainProcess] Setting default socket timeout to 30
[2017-11-30 08:28:58,946: INFO/MainProcess] beat: Starting...
[2017-11-30 08:28:58,946: DEBUG/MainProcess] DatabaseScheduler: initial read
[2017-11-30 08:28:58,946: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:58,968: DEBUG/MainProcess] DatabaseScheduler: Fetching database schedule
[2017-11-30 08:28:59,068: DEBUG/MainProcess] Current schedule:
<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) <crontab: 0 4 * * * (m/h/d/dM/MY)>>
[2017-11-30 08:28:59,115: INFO/MainProcess] DatabaseScheduler: Schedule changed.
[2017-11-30 08:28:59,115: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:59,115: DEBUG/MainProcess] DatabaseScheduler: Fetching database schedule
[2017-11-30 08:28:59,121: DEBUG/MainProcess] Current schedule:
<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) <crontab: 0 4 * * * (m/h/d/dM/MY)>>
[2017-11-30 08:28:59,122: DEBUG/MainProcess] beat: Ticking with max interval->5.00 seconds
[2017-11-30 08:28:59,138: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'capabilities': {'publisher_confirms': True, 'exchange_exchange_bindings': True, 'basic.nack': True, 'consumer_cancel_notify': True, 'connection.blocked': True, 'consumer_priorities': True, 'authentication_failure_close': True, 'per_consumer_qos': True, 'direct_reply_to': True}, 'cluster_name': 'rabbit<strong i="10">@Jupiter</strong>', 'copyright': 'Copyright (C) 2007-2017 Pivotal Software, Inc.', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'platform': 'Erlang/OTP 20.1', 'product': 'RabbitMQ', 'version': '3.6.14'}, mechanisms: [b'AMQPLAIN', b'PLAIN'], locales: ['en_US']
[2017-11-30 08:28:59,152: DEBUG/MainProcess] using channel_id: 1
[2017-11-30 08:28:59,153: DEBUG/MainProcess] Channel open
[2017-11-30 08:28:59,154: DEBUG/MainProcess] beat: Synchronizing schedule...
[2017-11-30 08:28:59,155: INFO/MainProcess] Writing entries...
[2017-11-30 08:28:59,160: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,161: DEBUG/MainProcess] celery.backend_cleanup sent. id->1dd626be-1dea-43ec-b000-ab61fdd33f9d
[2017-11-30 08:28:59,163: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,163: DEBUG/MainProcess] celery.backend_cleanup sent. id->7a9c7d44-e570-4a5a-9803-0a8e5111f035
[2017-11-30 08:28:59,165: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,166: DEBUG/MainProcess] celery.backend_cleanup sent. id->114ee8e1-4b3c-4f43-a632-9a249d7db364
[2017-11-30 08:28:59,167: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,168: DEBUG/MainProcess] celery.backend_cleanup sent. id->5b7f3825-d6c8-43a5-b056-2d567ec2c4df
[2017-11-30 08:28:59,170: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,171: DEBUG/MainProcess] celery.backend_cleanup sent. id->f1bfb936-0dd1-47b6-be10-3763d4446758
[2017-11-30 08:28:59,172: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,173: DEBUG/MainProcess] celery.backend_cleanup sent. id->7a12f2da-3717-45ab-b018-6b4fd7b83982
[2017-11-30 08:28:59,175: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,175: DEBUG/MainProcess] celery.backend_cleanup sent. id->64fbd61d-e80e-4a32-a49d-31ddc7e155c7
[2017-11-30 08:28:59,177: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,179: DEBUG/MainProcess] celery.backend_cleanup sent. id->ff38e88e-e7e8-4436-9724-9c416dde4d72
[2017-11-30 08:28:59,181: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
[2017-11-30 08:28:59,181: DEBUG/MainProcess] celery.backend_cleanup sent. id->d5116c47-df14-4f3e-a4d1-09087cd1af80
[2017-11-30 08:28:59,183: INFO/MainProcess] Scheduler: Sending due task celery.backend_cleanup (celery.backend_cleanup)
...

Und die Warteschlange füllt sich weiterhin mit einer Geschwindigkeit von 600/Sek.

# select name, last_run_at from django_celery_beat_periodictask;
           name           |          last_run_at          
--------------------------+-------------------------------
 celery.backend_cleanup   | 2017-11-30 16:40:59.352453-08 

Meine Einstellungen sind (ich habe alles eingestellt, was ich finden konnte, da die Dokumentation an mehreren Stellen extrem unübersichtlich und veraltet ist):

settings.py
CELERY_TIMEZONE = 'Canada/Pacific'
CELERY_ENABLE_UTC=False
USE_TZ = True
TIME_ZONE = 'Canada/Pacific'

celery.py
app = Celery('MyApp')
app.config_from_object('django.conf:settings', namespace='CELERY')
app.conf.timezone = 'Canada/Pacific'
app.conf.enable_utc = False

Es ist also klar, dass Sellerie die Aufgabe um 08:28:59-08 Uhr ausführt, aber beim Speichern der last_run_time werden immer noch 8 Stunden zur Zeit hinzugefügt, um 16:28:59-08 Uhr zu erhalten, bevor sie gespeichert wird die DB.

Ein kurzer Blick auf schedules.py sagt mir, dass wir ein Zeitdelta oder # Sekunden von crontab.is_due() zurückgeben.

Ich habe nicht mehr Zeit, hier weiter zu graben, aber offensichtlich bekommt etwas in der crontab-Klasse ein Zeitdelta zwischen der aktuellen Zeit und der aktuellen Zeit mit seinem tz replaced (nicht konvertiert).

Ich wäre sehr misstrauisch gegenüber Zeilen, die replace Zeitzonen enthalten.

In Ordnung -- Wenn jeder, der diesen Fehler hatte, den Master klonen und erneut testen könnte, behebt er das Problem für Sie. Meine PR wurde gestern Abend zusammengeführt und ich habe gerade überprüft, dass der Fehler behoben wurde, aber es wäre gut, eine zusätzliche Bestätigung für diejenigen zu erhalten, die den DB-Scheduler oder andere Backends verwenden. Vielen Dank!

976515108a4357397a3821332e944bb85550dfa2 wenden Sie dies an und überprüfen Sie