Clicking the Voxtype or fingerprint invitation did nothing. The launcher execs setsid, which forks because the transient unit's main process is already a process group leader, so the unit exits within milliseconds and systemd's default control-group kill took the still-starting terminal down with it. Run those units with KillMode=process instead. The invitation tests had also drifted from the two-unit design and were failing; teach the systemd-run mock to run the command it is given.
31 lines
1.4 KiB
Bash
31 lines
1.4 KiB
Bash
#!/bin/bash
|
|
|
|
set -e
|
|
|
|
show_invitation() {
|
|
if [[ -n $(omarchy-notification-send -u critical -g "Setup Fingerprint Reader" "Enable sudo and unlocking with your fingerprint." -a) ]]; then
|
|
# Launch the setup in its own transient unit so this invitation service can
|
|
# exit right after the click. If it stayed alive for the life of the setup
|
|
# terminal, the setup's omarchy-restart-shell would re-trigger this
|
|
# still-running *-invitation unit and pop the toast a second time.
|
|
# KillMode=process because the launcher's setsid forks and returns, so the
|
|
# unit's main process exits within milliseconds. The default control-group
|
|
# kill would take the terminal down with it before it ever appears.
|
|
systemd-run --user --collect --quiet -p KillMode=process \
|
|
--unit=omarchy-setup-security-fingerprint \
|
|
omarchy-launch-floating-terminal-with-presentation omarchy-setup-security-fingerprint
|
|
fi
|
|
}
|
|
|
|
if [[ ${1:-} == "--show" ]]; then
|
|
show_invitation
|
|
# Only invite when there's a reader to use and it isn't set up yet (the lock
|
|
# PAM file is the last thing the setup writes on success).
|
|
elif omarchy-hw-fingerprint && [[ ! -f /etc/pam.d/omarchy-lock-fingerprint ]] &&
|
|
omarchy-done ensure fingerprint-setup-invitation; then
|
|
# Keep the notification action alive after the update terminal closes.
|
|
systemd-run --user --collect --quiet --service-type=exec \
|
|
--unit=omarchy-fingerprint-setup-invitation \
|
|
bash "$0" --show
|
|
fi
|