| 19 Feb 2025 |
 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 |
| Arian | Basically turns it into one big mess. I don't understand why we have cycle detection in multiple output derivations though. Robert told me they might remove that feature from nix. But it never happened | 07:38:18 |
| Arian | So yeh if we want it we need to either make nix support cyclic outputs (which should be fine from correctness standpoint I think?) or we need to **heavily** patch systemd | 07:38:49 |
| Arian | * So yeh if we want it we need to either make nix support cyclic outputs (which should be fine from correctness standpoint I think?) or we need to **heavily** patch systemd | 07:39:16 |
| Arian | * We had multiple outputs build before but it broke with the introduction of sd-path | 07:39:40 |
| Arian | Ah but nix is multiple derivations? In that case heavy patching is the only solution. To get rid of the cycles between all of systemd's components | 07:40:36 |
 ElvishJerricco | In reply to @arianvp:matrix.org
Ah but nix is multiple derivations? In that case heavy patching is the only solution. To get rid of the cycles between all of systemd's components If we can do it in a way that seems like a benefit to upstream, then this isn't a problem | 09:28:23 |
| ElvishJerricco | I'd have to understand that cyclic dependency better | 09:29:13 |
| ElvishJerricco | Cyclic dependencies in general sound like a bad idea, so I imagine getting rid of it would be good for upstream too | 09:29:35 |
| ElvishJerricco | The systemd-repart.create-root test appears to be failing nondeterministically: https://hydra.nixos.org/build/290085282 | 11:04:53 |
| ElvishJerricco | I think that means systemd-fsck-root.service and systemd-repart.service are racing? | 11:05:23 |
 @denkn:denkn.at | In reply to @arianvp:matrix.org
Though the ordering will happen after The ready notification of course Thanks, yes, I call ready immidiatly, after starting, before the first bigger thing will be done. With ordering you meant, dependencies to this service, right? | 13:20:15 |
| Arian | In reply to @elvishjerricco:matrix.org
I'd have to understand that cyclic dependency better The whole path situation in systemd is a mess anyway. They're not using $prefix consistently . E.g. tmpfiles looks in /usr/lib
Given we could load all config from /etc anyway perhaps it's worth getting rid of all the $prefix dependencies in path lookups. Then sd-path stops having cyclic dependency | 14:20:42 |
| Arian | Run the `systemd-path` executable. You'll immediately understand the cyclic dependency due to the output it prints | 14:21:36 |
|  sss | 20:06:14 |
| 20 Feb 2025 |
|  thursdaddy set a profile picture. | 00:14:02 |
| 21 Feb 2025 |
 cleverca22 | having to fight systemd recovery mode today
somebody setup fstab to mount a device that didnt exist, on a headless machine
systemd had a panic attack, and refused to run ssh until somebody logged in on the "physical terminal" with the root pw (none was set), so the machine was basically bricked for 5 months, lol | 05:06:44 |
| cleverca22 | i know i can just set options = [ "nofail" ]; but then it just entirely ignores the mount-point, and starts services on the wrong disk | 05:07:17 |
| cleverca22 | how can i make systemd not have a total panic attack, but also not start certain services? | 05:07:35 |
| ElvishJerricco | cleverca22: You can use x-systemd.required-by=sshd.service,x-systemd.before=sshd.service as file system options | 05:59:33 |
| ElvishJerricco | see the systemd.mount manpage | 05:59:43 |
| ElvishJerricco | but x-systemd.required-by=sshd.service will basically remove the normal dependencies and just make the mount a dependency of sshd.service | 06:00:07 |
| ElvishJerricco | (sshd was a bad example because I think that's the opposite of what you want but I think you get the point :P) | 06:00:37 |
| ElvishJerricco | x-systemd.required-by= will make it so that the mount is not required by loca-fs.target, but instead just by the value of the option | 06:01:41 |
| ElvishJerricco | meaning if it fails, it won't send the system to emergency mode | 06:01:54 |
| ElvishJerricco | but of course a required-by relationship isn't an ordering relationship, hence why I also mentioned x-systemd.before= | 06:02:38 |
| cleverca22 | ElvishJerricco: ah, RequiresMountsFor is what i wanted, and does work | 06:09:18 |
| cleverca22 | but only if its in unitConfig, doh | 06:09:23 |
| cleverca22 | service.d/overrides.conf:18: Unknown key name 'RequiresMountsFor' in section 'Service', ignoring. | 06:09:34 |
