| 19 Feb 2025 |
 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 |
| 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 |
