| 17 Feb 2025 |
 m1cr0man | Iirc it is the second but I will test. Alas, that PR is broken when rebased due to changes needed in switch-to-configuration-ng. I wasn't able to complete it myself in the time I last had. See #nix-rfc-108:matrix.org | 19:22:08 |
 Arian | I don’t fully understand why we need to change stc. I naively assumed we could just call stc inside the container. but it has been a long time since I had all the context of 108 in my head | 19:25:36 |
 ma27 | In reply to @arianvp:matrix.org
I don’t fully understand why we need to change stc. I naively assumed we could just call stc inside the container. but it has been a long time since I had all the context of 108 in my head if you change the nixos config of a container, then sure you need to call stc inside the container.
if you change something else around the container (i.e. in the nspawn unit), you'll probably need to restart it. | 19:31:29 |
| Arian | why doesn’t that get handled by the systemd-nspawn@ unit already | 19:32:13 |
| Arian | it points to the nspawn config; which changes; triggers a restart | 19:32:23 |
| ma27 | because it depends on what has changed in the nspawn unit to know whether a restart or a reload (== call into the container to do stc) is needed, assuming we're talking about the 108 stuff.
it's been a while, so I don't remember the exact details though, sorry. | 19:37:21 |
|  Marcus changed their profile picture. | 21:38:11 |
 SigmaSquadron | Hi folks. I'm trying to use the PublicKeyFile setting in systemd.network.netdevs.<name>.wireguardPeers, as described in the manual page, but the module system keeps saying that's an invalid option. | 21:43:57 |
| SigmaSquadron | If I understood the module correctly, I think this has to be added manually in line 439-440 in nixos/modules/system/boot/networkd.nix? | 21:46:26 |
| m1cr0man | In reply to @arianvp:matrix.org
why doesn’t that get handled by the systemd-nspawn@ unit already The main problem is imperative containers rather than declarative ones. Since we're creating units ad hoc, we need to prevent the imperative ones getting stopped during config switch | 21:50:05 |
| SigmaSquadron | In reply to @sigmasquadron:matrix.org
If I understood the module correctly, I think this has to be added manually in line 439-440 in nixos/modules/system/boot/networkd.nix? if it is just that easy, i've opened https://github.com/nixos/nixpkgs/pull/382953 | 21:57:31 |
| 18 Feb 2025 |
 ElvishJerricco | ugh, this is why I really dislike how we type check networkd configs | 00:05:44 |
| ElvishJerricco | we really need a tool in upstream systemd for checking the validity of networkd files | 00:06:00 |
| Arian | I still have an experiment lying around for using systemd-analyze verify on systemd units at build time | 11:40:04 |
|  @stites:matrix.org left the room. | 12:54:41 |
 @denkn:denkn.at | Somebody know, if it is possible for services, which are oneshot to use sd_notify? Or it is more useful to set Type=notify, als if it is only a short running process, like started by a timer? | 15:09:04 |
 gdamjan | oneshot services are considered started/activated only when the process ends. so not sure if sd_notify makes sense for them | 15:18:28 |
| gdamjan | what's your use-case? | 15:18:32 |
| @denkn:denkn.at | It is a long-running process and it would be nice to check the progress. Logging would be an option, but it is only noisy, nobody needs it later. | 20:25:11 |
| @denkn:denkn.at | Eg backups. | 20:25:25 |
| Arian | Just make it Type=notify if it's long-lived | 20:26:36 |
| gdamjan | but then you'd … either loose ordering on the service, or risk the job timeout (ie how long systemd waits for a service to activate) | 23:22:30 |
| Arian | No you don't. Ordering works with Type=notify | 23:24:16 |
| Arian | Though the ordering will happen after The ready notification of course | 23:24:57 |
| gdamjan | that's what I meant | 23:51:55 |
| 19 Feb 2025 |
| ElvishJerricco | I wonder how hard it would be to do to systemd what we did to nix 2.26 and componentize the build | 06:17:06 |
| ElvishJerricco | we might be able to rid ourselves of an awful lot of the superfluous systemd dependencies in nixpkgs if we could do that. | 06:17:52 |
| Arian | We had multiple outputs build before | 07:36:34 |
| Arian | Biggest problem is sd-path.h which i still dont understand why it was added. Pointless complexity that isn't used internally | 07:37:06 |
| Arian | It causes a cyclic dependency between libsystemd and libsystemd-shared and libsystemd-core and cyclic dependency between libsystemd and some binaries iirc | 07:37:43 |
