acmesh-official / acme.sh

A pure Unix shell script implementing ACME client protocol
https://acme.sh
GNU General Public License v3.0
38.57k stars 4.91k forks source link

Fix "static" cronjob timing with the Docker image #4968

Open Hossy opened 7 months ago

Hossy commented 7 months ago

Item 1 (Problem): When the docker image is built (by GitHub), --install creates the cronjob and the random minute/hour selection becomes static for every instance of the image (worldwide) unless manually changed by the user.

Item 2 (Improvement): The two commits for #992 add a tool (cronie) which, at least currently with BusyBox 1.35.0 in Alpine 3.17, is unneeded and can be removed to make the image smaller while still keeping the intent and functionality of #992 (logging acme.sh cron output to the docker log by default).

I created PR #4969 with the following solutions:

Solution 1: Use @reboot cronjob to create the cronjob on first run of the container. In the case where the user has already run --install-cronjob before running the container with 'daemon,' --install-cronjob already doesn't duplicate/recreate the cronjob, so there is no loss of config.

Solution 2: Using BusyBox's crond (remove cronie), pass the -f parameter to run in the foreground which will cause stdout/stderr from cronjobs to print to docker log. crond remains PID 1. Redirecting output specifically to PID 1's stdout and stderr is no longer necessary using crond -f. This could later enable the option with --install-cronjob to create the cronjob without >/dev/null for use cases where the user wanted crond to mail output.

Neilpang commented 7 months ago

Using BusyBox's crond (remove cronie), pass the -f parameter

The default crond doesn't handle signals like ctrl+c. If you run the container in forground, and press ctrl+c to terminate the container, you will have to wait to timeout. This also affects docker stop and docker restart commands etc.

That's why the cronjob here is a little complex than normal. See the git history for the file.