[Bug] Cron schedule not respected & updater being run multiple times in one go

[Mahir007]

Is there an existing issue for this?

• [X] I have searched the existing issues

Version

2.9.2

Describe The Bug

I've changed the cron environment variable so that the updater runs every 24 hours instead of the default, however, this setting isn't being respected (despite saying that it has been set within the logs) with the updater still being run at every 5th minute. Additionally, the cron job runs the updater task multiple times (at once) for some reason. Checking the logs, I can see this has been happening since I created the container (before even changing the cron variable).

I'm running the latest version within Docker on a Synology NAS.

Steps To Reproduce

1. Create a container for this image on a Synology NAS.
2. Change the CRON environment variable from the default to "0 0 * * *".

Expected Behavior

The updater task is ran only once every 24 hours (or whatever the user inputs for the CRON variable).

YAML Configuration

No response

JS Configuration

No response

Relevant Output Log

2022-09-20T15:42:31	[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
2022-09-20T15:42:31	[s6-init] ensuring user provided files have correct perms...exited 0.
2022-09-20T15:42:31	[fix-attrs.d] applying ownership & permissions fixes...
2022-09-20T15:42:31	[fix-attrs.d] done.
2022-09-20T15:42:31	[cont-init.d] executing container initialization scripts...
2022-09-20T15:42:31	[cont-init.d] 10-adduser: executing... 
2022-09-20T15:42:31	usermod: no changes
2022-09-20T15:42:31	Initializing container
2022-09-20T15:42:31	User uid: 1030
2022-09-20T15:42:31	User gid: 100
2022-09-20T15:42:31	[cont-init.d] 10-adduser: exited 0.
2022-09-20T15:42:31	[cont-init.d] 11-cron: executing... 
2022-09-20T15:42:31	Setting crontab to 0 0 * * *
2022-09-20T15:42:31	[cont-init.d] 11-cron: exited 0.
2022-09-20T15:42:31	[cont-init.d] done.
2022-09-20T15:42:31	[services.d] starting services
2022-09-20T15:42:31	[services.d] done.
2022-09-20T15:42:32	[info] Cloudflare DDNS start
2022-09-20T15:42:33	[info] Skipped creating.
2022-09-20T15:42:33	[info] Updated * with 0:0:0:0:0:0:0:0
2022-09-20T15:42:33	[info] Skipped updating.
2022-09-20T15:42:33	[info] Updated mydomain.com with 1.2.3.4
2022-09-20T15:42:33	[info] Skipped creating.
2022-09-20T15:42:33	[info] Updated * with 1.2.3.4
2022-09-20T15:42:33	[info] Skipped updating.
2022-09-20T15:42:33	[info] Updated mydomain.com with 0:0:0:0:0:0:0:0
2022-09-20T15:42:33	[info] Cloudflare DDNS end
2022-09-20T15:42:33	crond[240]: crond (busybox 1.34.1) started, log level 8
2022-09-20T15:45:00	crond[240]: USER root pid 242 cmd run-parts /etc/periodic/15min
2022-09-20T15:45:00	crond[240]: USER root pid 243 cmd /app/cloudflare.sh
2022-09-20T15:45:00	crond[240]: USER root pid 244 cmd /app/cloudflare.sh
2022-09-20T15:45:00	crond[240]: USER root pid 245 cmd /app/cloudflare.sh
2022-09-20T15:45:00	crond[240]: USER root pid 256 cmd /app/cloudflare.sh
2022-09-20T15:45:00	crond[240]: USER root pid 257 cmd /app/cloudflare.sh
2022-09-20T15:45:01	[info] Cloudflare DDNS start
2022-09-20T15:45:01	[info] Cloudflare DDNS start
2022-09-20T15:45:01	[info] Cloudflare DDNS start
2022-09-20T15:45:01	[info] Cloudflare DDNS start
2022-09-20T15:45:01	[info] Cloudflare DDNS start
2022-09-20T15:45:04	[info] Skipped creating.
2022-09-20T15:45:04	[info] Updated * with 1.2.3.4
2022-09-20T15:45:05	[info] Skipped creating.
2022-09-20T15:45:05	[info] Updated * with 0:0:0:0:0:0:0:0
2022-09-20T15:45:05	[info] Skipped creating.
2022-09-20T15:45:05	[info] Updated * with 0:0:0:0:0:0:0:0
2022-09-20T15:45:05	[info] Skipped creating.
2022-09-20T15:45:05	[info] Updated * with 1.2.3.4
2022-09-20T15:45:05	[info] Skipped updating.
2022-09-20T15:45:05	[info] Updated mydomain.com with 1.2.3.4
2022-09-20T15:45:05	[info] Skipped creating.
2022-09-20T15:45:05	[info] Updated * with 0:0:0:0:0:0:0:0
2022-09-20T15:45:05	[info] Skipped updating.
2022-09-20T15:45:05	[info] Updated mydomain.com with 0:0:0:0:0:0:0:0
2022-09-20T15:45:05	[info] Skipped updating.
2022-09-20T15:45:05	[info] Updated mydomain.com with 0:0:0:0:0:0:0:0
2022-09-20T15:45:06	[info] Skipped creating.
2022-09-20T15:45:06	[info] Updated * with 0:0:0:0:0:0:0:0
2022-09-20T15:45:06	[info] Skipped updating.
2022-09-20T15:45:06	[info] Updated mydomain.com with 0:0:0:0:0:0:0:0
2022-09-20T15:45:06	[info] Skipped creating.
2022-09-20T15:45:06	[info] Updated * with 1.2.3.4
2022-09-20T15:45:06	[info] Skipped creating.
2022-09-20T15:45:06	[info] Updated * with 1.2.3.4
2022-09-20T15:45:06	[info] Skipped creating.
2022-09-20T15:45:06	[info] Updated * with 1.2.3.4
2022-09-20T15:45:06	[info] Skipped updating.
2022-09-20T15:45:06	[info] Updated mydomain.com with 1.2.3.4
2022-09-20T15:45:06	[info] Cloudflare DDNS end
2022-09-20T15:45:06	[info] Skipped updating.
2022-09-20T15:45:06	[info] Updated mydomain.com with 1.2.3.4
2022-09-20T15:45:06	[info] Skipped updating.
2022-09-20T15:45:06	[info] Updated mydomain.com with 0:0:0:0:0:0:0:0
2022-09-20T15:45:06	[info] Skipped creating.
2022-09-20T15:45:06	[info] Updated * with 0:0:0:0:0:0:0:0
2022-09-20T15:45:06	[info] Cloudflare DDNS end
2022-09-20T15:45:07	[info] Skipped updating.
2022-09-20T15:45:07	[info] Updated mydomain.com with 1.2.3.4
2022-09-20T15:45:07	[info] Cloudflare DDNS end
2022-09-20T15:45:07	[info] Skipped updating.
2022-09-20T15:45:07	[info] Updated mydomain.com with 0:0:0:0:0:0:0:0
2022-09-20T15:45:07	[info] Cloudflare DDNS end
2022-09-20T15:45:07	[info] Skipped updating.

[joshuaavalon]

Can you test the followings:

1. Does it run every 5 minutes without CRON?
2. After you set CRON, can you show the content of /etc/crontabs/root of the container?

[Mahir007]

Hi, apologies if I get some of the terminology wrong here (this is my first time interacting with cron) but I've finally had some time to do some proper testing. I found out by using the crontab -l command that there were a lot of scheduled jobs on the list. Additionally, every time I restarted the container to try out a new cron schedule, it had just added on a new job to the existing list. This explains why changing the CRON environment variable seemed to do nothing as it was still carrying out the default */5 * * * * in addition to the plethora of options I tried out.

To resolve this, I had to run the crontab -r command in the already running container before restarting it. This ensures that what I set in the CRON environment variable is the only schedule that is run. This also resolves the issue of the updater being ran multiple times in one go.

However, this doesn't fully resolve my issue as I'm now discovering a new one. If for whatever reason the container is stopped and then started again, then it will once again add on another job to cron schedule using whatever is entered in the environment variable (meaning I would now have two cron jobs running simultaneously at the same scheduled time).

I've tried removing the cron env from my container, however, the container still adds a new job to the crontab, just now without a schedule (which just reports the additional job as being ⠀⠀/app/cloudflare.sh compared to 0 2 * * * /app/cloudflare.sh for a normal job). This is something that is going to need fixing from your end (perhaps by ensuring the crontab is empty before setting the schedule?).

[joshuaavalon]

OK, I will take a look at this weekend.

[joshuaavalon]

I cannot reproduce your problem with the following config

version: "3"

services:
  ddns:
    image: ghcr.io/joshuaavalon/cloudflare-ddns:2.9.2
    restart: unless-stopped
    environment:
      - CRON=*/10 * * * *
    volumes:
      - ./config.yaml:/app/config.yaml

Hi, apologies if I get some of the terminology wrong here (this is my first time interacting with cron) but I've finally had some time to do some proper testing. I found out by using the crontab -l command that there were a lot of scheduled jobs on the list. Additionally, every time I restarted the container to try out a new cron schedule, it had just added on a new job to the existing list. This explains why changing the CRON environment variable seemed to do nothing as it was still carrying out the default */5 * * * * in addition to the plethora of options I tried out.

I do not think it is cause the this docker image unless you mount the volume.

This image only update the cron inside the container. All the changes is reset after container restarted. I have also confirmed it.

Please try the following and paste the crontab config:

1. First, use docker ps to find out the container name or id.
2. Enter the container with docker exec -it <container name or id> sh.
3. Run cat /etc/crontabs/root inside the container to get the crontab config.
4. Use exit to exit the container.

[sofute]

I have sort of the same issue, the cron does not fire, and I had multiple entries of the same. Doing the crontab -r and then reboot fix the problem. Every time I reboot otherwise, the problem comes back.

[joshuaavalon]

I have sort of the same issue, the cron does not fire, and I had multiple entries of the same. Doing the crontab -r and then reboot fix the problem. Every time I reboot otherwise, the problem comes back.

Could you follow the above step and paste the result?

[joshuaavalon]

Nevermind, I think I found the problem. It cause problem when you use docker compose stop instead of docker compose down.

[joshuaavalon]

:tada: This issue has been resolved in version 2.9.3 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: