fix(idle): lock with pgrep -xf breadlock so listen does not swallow lock_cmd #94
No reviewers
Labels
No labels
P0
P1
P2
P3
audio
bakery
boot
breadbug
bug
build
ci
dependencies
design
disk
docs
encryption
final
firewall
graphics
hardware
idle
installer
keybinds
nvidia
packages
phase-1
polish
recovery
reliability
reproducibility
secure-boot
security
shell
signing
snapshots
supply-chain
swap
tech-debt
theming
ux
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Breadway/bos!94
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/bos-92-idle-lock"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
lock_cmd = pidof breadlock || breadlocknever starts a locker.breadlock listenis autostarted at login, sopidof breadlockis always true and the|| breadlockthat actually locks never runs. Super+L (loginctl lock-session), the idle lock and the lock before suspend are all no-ops.The command is now
pgrep -xf breadlock >/dev/null || breadlock, which matches only a process whose whole argv is exactlybreadlockand notbreadlock listen. A second locker is still suppressed, and breadlock's own singleton handles the already-locked case.Existing installs keep the old line until BOS Settings rewrites it. That rewrite is bos-settings PR for the same card, and it replaces only this exact command, leaving a hand-written lock_cmd alone.
Refs BOS-92