| 4 Jul 2025 |
 Theuni | Now, we do need some unit that stays active (we used the -finished targets for this previously) so that s-t-c can trigger config updates. This was very indirect previously - moving this to a unit that is oneshot/remainafterexit (the "order" unit in my patch) makes config changes trigger more precisely. | 06:35:11 |
| Theuni | However, active units can't be triggered by timers, hence a "renew" unit that can be triggered by a timer. Initially I started out with the renew unit just being a "systemctl restart acme-${cert}", having all the tasks in a single bash script. I was somewhat wary of duplicating too much (bash) code (i did duplicate the nix code for the units) so I chose an inversion of control pattern where the renew unit then triggers the order unit again to make sure permission settings, relocating the updated certificates etc. happens in only a single place as well as triggering the reloads for consumers. | 06:37:21 |
| Theuni | (I'm using the chat to talk out my thought processes. Basically just🎈🦆ing here ...) | 06:39:22 |
| Theuni | *
- the assurance: the files referenced in your config file are now available and are (syntactically) valid ssl certificates. Go forth and start!
| 06:39:57 |
| Theuni | That inversion makes the dependencies muddied again. I could split it up in more units, moving the post-processing code in a separate unit, or just use a shared (execstartpost) script (or partial). | 06:42:16 |
| Theuni | Hmm. Consolidating multiple certificates renewing at the same time isn't much of an issue I guess as we distribute the renewal timers over time anyway. | 06:43:05 |
| Theuni | * Hmm. Consolidating client reload signals for multiple certificates renewing at the same time isn't much of an issue I guess as we distribute the renewal timers over time anyway. | 06:43:18 |
