| 19 Feb 2025 |
 emily | oneshots are only considered started after they complete, right? | 16:59:29 |
| emily | so the timer can probably start two of them at once? which would be bad. we should probably not be using oneshot | 16:59:40 |
 hexa |
the service manager will consider the unit up after the main process exits
| 17:00:16 |
| hexa | *
similar to simple; however, the service manager will consider the unit up after the main process exits
| 17:00:26 |
| emily | right | 17:00:34 |
| emily | well I dunno, it's probably safe to specify like 12–24 hours assuming that the timer will not try to run lego again if it's still running from the previous timer run | 17:00:54 |
| emily | I don't understand oneshot well enough to say whether that's the case | 17:01:00 |
| hexa | 18h + AccuracySecs | 17:01:33 |
| hexa | which would be between 18 and 22 hours | 17:01:43 |
| hexa | or 19-23 | 17:02:01 |
| emily | I think the only risk of a long value is the timer triggering again and starting lego again | 17:02:08 |
| emily | I just don't know if that's how it actually works | 17:02:11 |
| emily | I think systemd keeps track of services that are "starting" but not started | 17:02:19 |
| emily | so it may not try to run lego again if it's blocking from before | 17:02:27 |
| hexa |
Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running.
https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
| 17:05:02 |
| emily | but oneshots aren't "active" until they finish, right? | 17:11:56 |
| emily | or maybe they're "active" but not "running"? | 17:12:05 |
| hexa | they should be in activating while running iirc | 17:19:01 |
| 20 Feb 2025 |
| hexa | ok, merged lego 4.22.2 | 18:05:34 |
| hexa | so now we have ari enabled with wait time 0 | 18:05:41 |
| hexa | so at least we'd get immediate cert renewal if within a requested renewal window even if the cert was valid for longer than 30 days | 18:06:20 |
| hexa | --ari-disable Do not use the renewalInfo endpoint (draft-ietf-acme-ari) to check if a certificate should be renewed. (default: false)
| 18:07:53 |
 ThinkChaos | Did they remove --ari-enable or do they have both now? 😄 | 18:08:48 |
| emily | is 0 "no wait" or "indefinite"? | 20:31:12 |
| hexa | no wait aiui | 20:55:07 |
| hexa | yes, ari is default on now and you can disable it | 20:55:20 |
| 21 Feb 2025 |
| emily |
You’ll also want to be sure your ACME client is running frequently - both for the sake of renewing short-lived certificates and so as to take advantage of ACME Renewal Information (ARI). ARI allows Let’s Encrypt to notify your client if it should renew early for some reason. ARI checks should happen at least once per day, and short-lived certificates should be renewed every two to three days, so we recommend having your client run at least once per day.
| 16:04:44 |
| emily | wonder if we should consider moving to 2×/day | 16:04:52 |
| emily | (https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued/) | 16:04:57 |
| 22 Feb 2025 |
 m1cr0man | I mean we only ever had it > 1 day for LE's sake (DDOS) 😅 I don't see why we couldn't do 2x/day.
Sorry just catching up on this all now. Was on holidays. | 00:26:31 |
