Apologies, I forgot to say that the script I linked is meant to be a temporary workaround until proper remote unlocking support is added. I posted it as a reference for those who stumble across this bug report looking for a way to get remote unlocking to work right away.
Regarding the original proposed patch: I agree that it is probably not a good idea to run /scripts/local-top/cryptroot a second time while another instance is still running. Aside from the benign but scary/confusing error messages, issues can arise if cryptroot isn't idempotent. I prefer the approach in your latest patch. I have a few questions, comments, and suggestions for improvement (all minor): * use strdup() instead of strlen()+malloc()+strcpy() * sizeof(char) is always 1 (see C99 6.5.3.4p3) * add a free(prompt2) to keep static analyzers and valgrind happy * why SIGKILL instead of SIGTERM? seems too aggressive * perhaps add a waitpid() after the kill() to ensure that a second plymouth won't be run before the first one exits * why does cryptroot-unlock use /bin/ash instead of /bin/sh? * POSIX has deprecated test's -a and -o operators; the following is safer: [ -t 0 ] && [ -x "$ASKPASS" ] * can you use askpass itself to prompt for the password, or would the multiple askpass instances cause problems? * echo might interpret backslashes or an initial dash in the password; the following is safer: printf %s "$REPLY" >$PASSFIFO * there are lots of BusyBox ashisms in the cryptroot-unlock script, many of which can be easily replaced with POSIX conformant code -Richard