🐛 The extend_lock job spams the hell out of your logs

[coredumperror]

Bug Description

I want to use django-crontask, but the fact that I get these two logs every 5 seconds is infuriating. How do I make it stop?

access_admin       | SYSLOG 2026-01-09T23:57:04.016898Z [info     ] Running job "contask.utils.lock.extend (trigger: interval[0:00:05], next run at: 2026-01-09 15:57:09 PST)" (scheduled at 2026-01-09 15:57:04.010919-08:00) [apscheduler.executors.default]
access_admin       | SYSLOG 2026-01-09T23:57:04.018155Z [info     ] Job "contask.utils.lock.extend (trigger: interval[0:00:05], next run at: 2026-01-09 15:57:09 PST)" executed successfully [apscheduler.executors.default]

Also that name has a typo. Should start with "crontask", not "contask". That's defined on line 73 in the management command.

Expected Behavior

Not getting my logs spammed with useless junk every 5 seconds.

Version

1.1.1

Stack trace

No response

Steps to Reproduce

No response

[codingjoe]

Hi @coredumperror 👋,

Thank you for reaching out. Based on the information, the provided logger in question seems to be apscheduler.executors.default. In other words, not really part of this package, but a dependency. I agree that APScheduler can be pretty verbose at times.

But fear not, Python has a built-in solution for that. You can configure how any logger is handled. In Django you can do this via the LOGGING setting.

You'd need to set up something like this:

# settings.py
LOGGING = {
    "version": 1,
    # other things like handlers
    "loggers": {
        "": {"handlers": ["console"], "level": "INFO"},
        "apscheduler.executors.default": {"handlers": ["console"], "level": "WARNING"},
    },
}

Note how the level is increased to warning, therefore dropping all info logs.

I hope this helps. Please let me know if you need any assistance.

Best
Johannes

---

PS: Please be mindful of our code of conduct. I try to carefully respond to all questions in my spare time. You seem to be a native speaker (unlike me), and I am sure you can find ways to formulate your questions with a little more appreciation for open-source software.

[coredumperror]

Apologies for the harsh tone of my original issue post. I was dealing with a lot of frustrating stuff last Friday.

Thanks for the idea of using the python logging config to quiet this down. That'll be much better than the hacky monkey patch I came up with.

I'll share what I ultimately come up with here, in case it might be helpful to others.

[codingjoe]

No worries, we all have those Fridays. Happy I could help. Cheers!

[coredumperror]

OK, here's what I put into my Django settings.py to efficiently silence these spammy logs:

def ignore_spammy_task_logs(record):
    """
    Silences log messages for certain especially spammy tasks.
    """
    # NOTE: If you need to debug this function by adding print statements, you MUST
    # use print("message", flush=True), or your prints will never appear.
    spammy_task_messages = [
        # These get emitted every 5 seconds due to an implementation detail in django-crontask.
        "crontask.utils.lock.extend",
        # This hides all but the ﮩ٨ـﮩﮩ٨ـ♡ﮩ٨ـﮩﮩ٨ـ log from our custom heartbeat task.
        "heartbeat_task",
    ]
    return not any(message in record.getMessage() for message in spammy_task_messages)

LOGGING = {
    ...
    "filters": {
        "ignore_spammy_task_logs": {
            "()": "django.utils.log.CallbackFilter",
            "callback": ignore_spammy_task_logs,
        },
        ...
    },
    ...
    "handlers": {
        "structlog_console": {
            "level": "DEBUG",
            "class": "logging.StreamHandler",
            "formatter": "stdout",
            "filters": ["ignore_spammy_task_logs"],
        },
        ...
    }
    ...
    "root": {
        # Set up the root logger to use our console handler.
        "handlers": ["structlog_console"],
        "level": "INFO",
    },
    "formatters": {
        # This formatter writes human-readable logs using structlog.
        "stdout": {
            "()": structlog.stdlib.ProcessorFormatter,
            "processor": structlog.dev.ConsoleRenderer(pad_level=False)
        },
        ...
    }
}

...s represent parts of my LOGGING dict that I skipped since they aren't relevant to this issue. You can use ignore_spammy_task_logs to silence any number of specific log messages that you don't want to see.

[johndoe46]

Hello,

Excellent solution.

You can remove the heartbeat task with --no-heartbeat. It was useful for us since we use the django-tasks-db backend and these tasks keep piling up in the table.

@codingjoe Is this lock.extend always necessary though ? From what I understand by reading the source it's only ever useful when using Redis ?

Anyway thanks for sharing django-crontask, it's really useful and bridges a gap.

[codingjoe]

Hi @johndoe46,

Excellent question. The heartbeat isn't needed but is helpful to monitor your task processing pipeline, especially in combination with Sentry's cron feature, which acts as a dead man's snitch.

The lock is needed to ensure only a single scheduler is running. Multiple schedulers would cause task duplication, which you probably don't want. It's not really related to Redis. However, Redis is the easiest way to get a distributed lock implementation in Django. However, if you are running a small project without containerization and recovery, which could spawn more than one scheduler, you are most likely OK without using the Redis lock. We could also add other lock implementations, like a file-based one. However, this would only work on a single logical machine.

Let me know should you have any further questions.

Cheers!
Joe

[johndoe46]

We switched from huey to crontask (+django-tasks-db) and so far it's fine. No distributed queue here, so it's easy to manage.