[Cu3PO42]

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]

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.

[Cu3PO42]

Depending on the timeouts involved, I imagined it might still happen if you had automatic retry.

And thanks for the pointer, I actually have the same fix in my config with the nice benefit of only adding a single non-changing entry to /etc/shells. It might be worth up streaming something like this to nix-darwin, so we don't all go implement essentially the same fix.

[xrisk]

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]

Apple does a “userspace reboot” (killing all processes) after device unlock to categorically solve this problem

[floam]

That sounds like a perfect use case for the wait4path utility that’s shipped with the OS for decades