| 19 Feb 2025 |
emily | this isn't helpful, the discussion is about the interface lego is providing for it | 16:53:28 |
Sandro 🐧 | I just wanted to make sure we are all on the same page, didn't know that you already know everything | 16:54:12 |
emily | this is the sticking point, it doesn't seem like a low --ari-wait-to-renew-duration will actually give you a normal "poll for renewal" interface | 16:54:51 |
emily | it will just look at the recommended renewal and go "nope that's too long" and do it early | 16:55:01 |
emily | (again, based on my quick reading of the Go that could be wrong) | 16:55:07 |
emily | so it seems like we need to let it block indefinitely, which is a total inversion of how our current module works, and we can't even conditionalize on whether certs are using ARI in the Nix code because that's downstream of server-side config | 16:55:37 |
emily | maybe we can just let it wait indefinitely and the timer will only fire once? | 16:55:52 |
emily | this is why ACME really wants a long-lived daemon :( | 16:56:07 |
hexa | sorry, I don't follow your conclusion here | 16:56:37 |
emily | ok, let's say ARI is enabled, the ACME server says "renew in 2 months", but you pass --ari-wait-to-renew-duration 5m | 16:57:22 |
hexa | https://github.com/go-acme/lego/blob/v4.22.2/certificate/renewal.go | 16:57:49 |
emily | oh hmm | 16:57:52 |
hexa | beyond my willingless to sleep | 16:57:52 |
hexa | so returns nil | 16:58:00 |
emily | ok I think I misread ShouldRenewAt | 16:58:01 |
emily | right | 16:58:08 |
emily | ok, then I think we just set it to a time that will definitely not overlap with the next timer. 23h is too long because of our time skewing | 16:58:24 |
emily | I think theoretically you can end up with it running at 23:59 one day and 00:01 the next. not sure how it works exactly | 16:58:57 |
emily | but I guess systemd timers will never start twice at once? | 16:59:01 |
hexa | oh yeah, we do AccuracySecs=14400s | 16:59:03 |
hexa | good call | 16:59:04 |
emily | I'm not sure what Type= we have on the ACME services | 16:59:08 |
hexa | oneshot | 16:59:18 |
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 |