На FreeBSD используйте procstat -i
, чтобы увидеть, какие сигналы игнорируются процессом. Аналогично, procstat -j
, чтобы увидеть, какие сигналы блокируются потоками процесса. Обе команды показывают, ожидается ли сигнал.
Пример вывода:
$ procstat -i 38540
PID COMM SIG FLAGS
38540 nsulfd HUP -I-
38540 nsulfd INT -I-
38540 nsulfd QUIT -I-
38540 nsulfd ILL ---
38540 nsulfd TRAP ---
...
$ procstat -j 38540
PID TID COMM SIG ФЛАГИ
38540 101220 nsulfd HUP --
38540 101220 nsulfd INT --
38540 101220 nsulfd QUIT -B
38540 101220 nsulfd ILL --
38540 101220 nsulfd TRAP --
...
See procstat(1).
В KDE и некоторых других средах рабочего стола вы можете прослушивать dbus для интерфейса org.freedesktop.ScreenSaver
.
Сценарий для этого будет выглядеть следующим образом:
dbus-monitor --session "type='signal',interface='org.freedesktop.ScreenSaver'" |
while read x; do
case "$x" in
# You can call your desired script in the following line instead of the echo:
*"boolean true"*) echo SCREEN_LOCKED;;
*"boolean false"*) echo SCREEN_UNLOCKED;;
esac
done
См. также этот вопрос для получения дополнительной информации.
Одним из способов обхода, который я могу придумать, является (если вы обычно используете сочетание клавиш для блокировки) повторно связать сочетание клавиш с блокировкой, чтобы вместо этого выполнить ваш скрипт, затем блокировка сеанса, что может быть достигнуто с помощью этой команды в вашем скрипте:
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
Тем не менее, я не в kde, поэтому не могу это проверить.
Думаю, что если не использовать сочетание клавиш, сделать это будет сложнее. Одним из возможных методов является разветвление программы блокировки для поиска сценария и его выполнения.
Это может зависеть от того, какую версию KDE вы используете, но если у вас есть запись Уведомления в настройках системы, вы можете использовать элементы управления Заставка для запуска скрипты как на блокировку экрана, так и на разблокировку.