| 5 Mar 2025 |
 eliasp | hmm, according to strace, it reads the runtime override before the on from the Nix store... I'll have to dig through the codebase now to see, whether "order of reading" == "order of evaluation" | 10:55:33 |
| eliasp | hmm, according to strace, it reads the runtime override before the one from the Nix store... I'll have to dig through the codebase now to see, whether "order of reading" == "order of evaluation" | 10:55:42 |
| eliasp | can't make any sense of it... implementation looks correct to me | 11:42:51 |
 Alyssa Ross | iirc systemd priority is /etc -> /run -> /usr, so runtime overrides don't override /etc (for some reason) | 12:08:45 |
| eliasp | oh, that'd render runtime overrides completely pointless for most NixOS services... double-checking the sd docs | 13:22:08 |
 K900 | I don't think that's how it works | 13:22:30 |
| K900 | /run should win | 13:22:32 |
| Alyssa Ross | You'd think so | 13:24:45 |
| Alyssa Ross | That would be the sensible and intuitive design | 13:25:11 |
| eliasp | From the docs:
Drop-in files in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/.
| 13:31:11 |
| eliasp | But looking at the table in "Unit File Load Path", it might be possible to use /run/systemd/transient instead… | 13:33:29 |
| eliasp | unfortunately, systemctl edit doesn't understand --transient, so this has to be handled manually…
but we might want to rework the patch 0016-systemctl-edit-suggest-systemdctl-edit-runtime-on-sy.patch pointing people towards --runtime | 13:35:35 |
 Ramses 🇵🇸 | Yeah, I ran into this in the past as well, /etc takes priority over /run, unfortunately. I didn't know about the transient stuff | 15:26:12 |
| Ramses 🇵🇸 | I don't think you're supposed to use the transient stuff for this, I think it's what's used by systemd-run | 15:27:44 |
 Sandro 🐧 | Would anyone be willing to help me figure out how to combine the two glitchtip services and the glitchtip.socket so that they all reside under /run/glitchtip and don't delete the socket on themselves and restarting one doesn't leave the socket missing? I tried copying from paperless but it doesn't fully work yet.
https://github.com/SuperSandro2000/nixpkgs/commit/f1bb998afa34c6fa46236370d72c1d1904a41f34 | 15:52:13 |
 Arian | Dont. You shouldn't put sockets in RuntimeDirectory | 16:02:26 |
| Arian | Sockets go in /run (top-level) | 16:02:32 |
| Arian | RuntimeDirectory is private to the service. A socket is per definition something to be shared. Don't put it in RuntimeDirectory | 16:03:05 |
| Arian | There is RuntimeDirectoryPreserve as a workaround | 16:03:33 |
| Arian | But usually it's the wrong choice to put a socket managed by a .socket. In a directory managed by a .service | 16:03:53 |
| Sandro 🐧 | Also bad eg: you cannot bind mount them then because on restart the bind mount breaks | 16:04:30 |
| Sandro 🐧 | it works for paperless already, so I guess it cannot be to bad | 16:04:50 |
| Sandro 🐧 | I don't think I want that tbh 😅 | 16:05:02 |
| Arian | yeh don’t :D | 16:11:07 |
| Arian | I’d suggest always putting a socket in /run/servicename.sock | 16:11:19 |
| Sandro 🐧 | How does it then work with permissions? | 16:17:48 |
| Sandro 🐧 | also on my system I have one socket there which is a symlink to somewhere else | 16:17:58 |
 @adam:robins.wtf | the socket unit can specify permissions, no? | 16:32:03 |
| Sandro 🐧 | yeah, sometimes, but often they are the equivalent of 777 | 16:35:08 |
| Arian | SockerUser and SocketMode.
But usually unix domain sockets use SO_PEERCRED to figure out the user of the caller and make decisions on that
| 21:14:21 |
