Scheduled script not scheduled anymore after re-creating the container.

dga-nagra commented 3 months ago

Current Behavior

If we delete the container and create a new one, the scripts are not scheduled anymore. It is apparently due to the scheduling being done using crontab which won't persist.

NOTE: There should be a comment section for bug report. Also, even if the bug is reproducible with docker compose, we are using AWS ECS for the deployment and the public image => I had no repository to run "git rev-parse head", I had to find the corresponding commit of the image we use

Expected Behavior

The scheduling still work. Ideally, the scheduling must be stored in the database (to be reported to netbox?)

Docker Compose Version

Docker Compose version v2.27.0

Docker Version

Client: Docker Engine - Community
 Version:           26.1.3
 API version:       1.45
 Go version:        go1.21.10
 Git commit:        b72abbb
 Built:             Thu May 16 08:33:42 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.3
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.10
  Git commit:       8e96db1
  Built:            Thu May 16 08:33:42 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.31
  GitCommit:        e377cd56a71523140ca6ae87e30244719194a521
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

The git Revision

0c99ff8b5663db3e0db5a45660cebda9f917508b

The git Status

On branch release
Your branch is up to date with 'origin/release'.

nothing to commit, working tree clean

Startup Command

docker compose up

NetBox Logs

...

Content of docker-compose.override.yml

services:
  netbox:
    ports:
      - "8000:8080"
    # If you want the Nginx unit status page visible from the
    # outside of the container add the following port mapping:
    # - "8001:8081"
    # healthcheck:
      # Time for which the health check can fail after the container is started.
      # This depends mostly on the performance of your database. On the first start,
      # when all tables need to be created the start_period should be higher than on
      # subsequent starts. For the first start after major version upgrades of NetBox
      # the start_period might also need to be set higher.
      # Default value in our docker-compose.yml is 60s
      # start_period: 90s
    # environment:
      # SKIP_SUPERUSER: "false"
      # SUPERUSER_API_TOKEN: ""
      # SUPERUSER_EMAIL: ""
      # SUPERUSER_NAME: ""
      # SUPERUSER_PASSWORD: ""

tobiasge commented 2 months ago

I think the scheduled jobs are stored in a Redis queue, so they should not be deleted if the containers are restarted. If you deleted the volume from the Redis containers then, the jobs are gone.

dga-nagra commented 2 months ago

@tobiasge Hi, we use AWS elasticache service that never goes down for redis, and AWS RDS for postgres. There shouldn't be any issue on this side but still, the scheduling is apparently lost after we restart the containers

netbox-community / netbox-docker