| 19 Feb 2025 |
 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 |
| ElvishJerricco | cleverca22: Sure, though that requires adding nofail to the file system if you want it to not cause emergency mode | 06:10:05 |
| cleverca22 | yep, i already added nofail, and that caused an issue of the service starting without the disk | 06:12:43 |
| cleverca22 | nofail plus RequiresMountsFor results in no emergency mode, and the service doesnt start | 06:13:01 |
| cleverca22 | Feb 21 06:10:16 backend1 systemd[1]: ipfs.service: Job ipfs.service/start failed with result 'dependency'. | 06:13:32 |
| cleverca22 | thats perfect | 06:13:35 |
| ElvishJerricco | yea, that's nearly the same thing as simply adding x-systemd.required-by=foo.service,x-systemd.before=foo.service, with the only difference being that my way doesn't mount the file system if foo.service isn't scheduled at boot. | 06:15:29 |
| cleverca22 | under normal conditions, it should mount at boot, and start the service at boot | 06:19:59 |
| ElvishJerricco | yea, the difference is negligible | 06:20:12 |
| cleverca22 | the problem, is that somebody put the fileSystems config in a shared module
and then deployed it to a dev machine in digital ocean
a machine lacking the DO volume.... | 06:20:26 |
| ElvishJerricco | it would only matter if you wanted to mask the service for some reason | 06:20:27 |
| cleverca22 | so the machine instantly fell over | 06:20:32 |
| cleverca22 | and nobody bothered fixing it, for 5 months | 06:20:39 |
| ElvishJerricco | It'll mount at normally boot with either way | 06:21:28 |
| ElvishJerricco | but the x-systemd. way would not mount if you masked the service for some reason | 06:21:54 |
