▲ | Cu3PO42 4 days ago | |||||||
Neat. Though I wonder if this suffers from the same race condition that the graphical session does when your shell is stored on a data volume. Specifically, if you restart and opt to restart apps, they can come up before all volumes have been decrypted and mounted. If your shell is on one such volume, your terminal emulator may fail to start, for example. This can happen when using Nix to install your shell, for example. I imagine this may be even easier to hit over SSH unless the underlying problem was resolved. | ||||||||
▲ | lilyball 4 days ago | parent | next [-] | |||||||
Unlock over SSH terminates the connection after unlocking the data volume, so it doesn't even attempt to start the shell until you reconnect after it's fully booted up. FWIW you can fix the shell issue by wrapping your shell in a shim that essentially runs wait4path on the nix store before exec'ing your real shell. I set up my environment to install that shim binary directly onto the data volume at a known path so it can be used as my login shell. | ||||||||
| ||||||||
▲ | xrisk 4 days ago | parent | prev | next [-] | |||||||
This is such a hilarious failure mode. I would never have imagined something like this to a problem. In the case of SSH though, I assume retrying after a second or so would be enough. You probably have some sort of retry mechanism to deal with network failures anyway. | ||||||||
▲ | conradev 4 days ago | parent | prev | next [-] | |||||||
Apple does a “userspace reboot” (killing all processes) after device unlock to categorically solve this problem | ||||||||
▲ | floam 4 days ago | parent | prev [-] | |||||||
That sounds like a perfect use case for the wait4path utility that’s shipped with the OS for decades |