Enable --keep-going by default for cronjob-operations. #486

Closed
opened 2025-12-29 01:26:02 +01:00 by adam · 1 comment
Owner

Originally created by @someone-somenet-org on GitHub (Jul 20, 2020).

What happened

We host a few wikis for random student's projects and allow them to use their own domain names.

Over the weekend some of our hosted wikis became unreachable (cert expired), because our cronjob was this:
@weekly letsencrypt /usr/bin/dehydrated -c; /usr/bin/dehydrated -gc

Turns out: dehydrated aborts by default on the first error and one domain expired and failed to be renewed, aborting the renew operation for all subsequent domains. (And we failed to check on the "error" mails from dehydrated/cron, because you get them even if no error occurs so it turns out: all of us admins ignore them)

Proposal

Change the default of --keep-going to be enabled by default (and add a --abort-on-error or something like that to cover the usecase of actually wanting to fail on the first error.)

Originally created by @someone-somenet-org on GitHub (Jul 20, 2020). ### What happened We host a few wikis for random student's projects and allow them to use their own domain names. Over the weekend some of our hosted wikis became unreachable (cert expired), because our cronjob was this: `@weekly letsencrypt /usr/bin/dehydrated -c; /usr/bin/dehydrated -gc` Turns out: dehydrated aborts by default on the first error and one domain expired and failed to be renewed, aborting the renew operation for all subsequent domains. (And we failed to check on the "error" mails from dehydrated/cron, because you get them even if no error occurs so it turns out: all of us admins ignore them) ### Proposal Change the default of `--keep-going` to be enabled by default (and add a `--abort-on-error` or something like that to cover the usecase of actually wanting to fail on the first error.)
adam closed this issue 2025-12-29 01:26:02 +01:00
Author
Owner

@lukas2511 commented on GitHub (Sep 17, 2020):

Thanks for reporting. Unfortunately I think it's a bad idea to change this behavior as many people might already have built their tooling around this exact behavior and it could potentially silently break their setups. I think the current way is documented enough not to be a problem.

@lukas2511 commented on GitHub (Sep 17, 2020): Thanks for reporting. Unfortunately I think it's a bad idea to change this behavior as many people might already have built their tooling around this exact behavior and it could potentially silently break their setups. I think the current way is documented enough not to be a problem.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#486