Правильный способ выполнения скрипта при возобновлении работы из приостановки

Убунту 20.04

Я провел несколько поисков способов выполнения скрипта или команды при возобновлении работы из режима ожидания и придумал несколько различных способов сделать это, например описанный здесь, но ни один из них не сработал для меня.

Первый способ, который я нашел, это использование pm-utils. По-видимому, этот метод был удален из Ubuntu начиная с 15.04 или около того.

Следующее, что я нашел, это использовать systemd/system-sleep — это тоже не сработало для меня. Я попытался создать скрипт в каталоге /usr/lib/systemd/system-sleep, также попробовал каталог /lib/systemd/system-sleep (который, по-видимому, связан с /usr/lib/systemd/system-sleep, поскольку изменения в одно появляется в другом). Я также попытался изменить уже существующий скрипт под названием hdparm - это также не сработало (мотивация, которую я сделал, была но файл так и не появился).

Итак, может ли кто-нибудь сказать мне, как правильно запустить скрипт или команду при возобновлении работы?

Спасибо за любой вклад/предложения/веб-сайты - особенно с подробными инструкциями и объяснениями того, что происходит на этом пути...

Редактировать:

Основываясь на ответе Матиго, я сделал следующее:

В /etc/pm/sleep.d я создал скрипт с именем 00xmodkey.sh. Я добавил в этот файл следующий код скрипта, затем убедился, что он принадлежит пользователю root и имеет права на выполнение.

Содержимое скрипта (в качестве оболочки пробовали и sh, и bash):

      #!/bin/sh

case "${1}" in
    resume|thaw) 
        touch /tmp/xmodlog.log
        echo "$(date) - lib testing" >> /tmp/xmodlog.log
        ;;
esac

Подтвержденные права собственности и разрешения:

      ls -l 00xmodkey.sh
-rwxr-xr-x 1 root root 257 Feb  4 22:49 00xmodkey.sh

Затем я перевел систему в режим ожидания. Ждал `~ 20 секунд. Разбудил систему. Поискал в /tmp файл с именем xmodlog.log. Нет файла.

Значит, я все еще что-то упускаю...

Редактировать 2:

Основываясь на ответе blitzter47, я разместил скрипт в называется 20xmodmap, который я впоследствии пометил как исполняемый. Файл сценария содержал следующее:

      #!/bin/sh
# Remap a key to allow context menu access

case "$1" in
    post) 
        echo "$(date) - lib testing" >> /tmp/xmodlog.log
        ;;
    *)
        echo "$(date) - $(1) $(2) - lib testing" >> /tmp/xmodlog.log
        ;;
esac

exit 0

Файл xmodlog.log никогда не отображается в /tmp, поэтому либо что-то не так со скриптом, либо скрипт никогда не выполняется.

Редактировать 3:

Основываясь на комментариях ниже, я изменил сценарий, чтобы явно указать путь к командам, и использовал скорее, чем . Никаких изменений в результатах. Также попытался переместить местоположение временного файла, просто чтобы убедиться, что это не произошло что-то странное из-за использования , но опять же без изменений. Вот модифицированный скрипт:

      #!/bin/sh
# Remap a key to allow context menu access

case "$1" in
    post) 
        /bin/touch /home/tracy/xmodlog.log
        ;;
    *)
        /bin/touch /home/tracy/xmodlog.log
        ;;
esac

exit 0

Таким образом, даже со всем, что указано явно, и с использованием папки, к которой, как я знаю, есть доступ у моего пользователя (система должна иметь доступ ко всему, если она работает в системном контексте), она все равно не работает.

Редактировать 4:

Запрошенный вывод из «sudo systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target»:

      tracy@tracy-HP17:~$ sudo systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target
● sleep.target - Sleep
     Loaded: loaded (/lib/systemd/system/sleep.target; static; vendor preset: e>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

● suspend.target - Suspend
     Loaded: loaded (/lib/systemd/system/suspend.target; static; vendor preset:>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

● hibernate.target - Hibernate
     Loaded: loaded (/lib/systemd/system/hibernate.target; static; vendor prese>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

● hybrid-sleep.target - Hybrid Suspend+Hibernate
     Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static; vendor pr>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

Редактировать 5:

Итак, я зашел и почистил скрипт, и убедился, что все работает (запуск из командной строки работает). Вот команды и результат настройки и запуска скрипта:

      tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ which ls
/usr/bin/ls
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ which echo
/usr/bin/echo
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls -la /lib/systemd/system-sleep
total 32
drwxr-xr-x  2 root root  4096 Mar  9 21:30 .
drwxr-xr-x 17 root root 12288 Jan 19 13:39 ..
-rwxr-xr-x  1 root root   405 Mar  9 21:22 20xmodmap
-rwxr-xr-x  1 root root   148 Feb 26 22:01 hdparm
-rw-r--r--  1 root root   404 Mar  9 20:54 holding.txt
-rwxr-xr-x  1 root root   219 Jul 21  2020 unattended-upgrades
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ nl 20xmodmap
     1  #!/bin/sh
     2  # Remap a key to allow context menu access
       
     3  /usr/bin/ls /home/tracy/TestScript/
       
     4  case "$1" in
     5      post) 
     6  #       /usr/bin/touch /home/tracy/TestScript/xmodlog.log
     7          /usr/bin/echo "post" > /home/tracy/TestScript/xmodlog.log
     8          ;;
     9      *)
    10  #       /usr/bin/touch /home/tracy/TestScript/xmodlog.log
    11          /usr/bin/echo "default" > /home/tracy/TestScript/xmodlog.log
    12          ;;
    13  esac
       
    14  /usr/bin/ls /home/tracy/TestScript/
       
    15  exit 0
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls /home/tracy/TestScript
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ sudo ./20xmodmap
[sudo] password for tracy: 
xmodlog.log
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls /home/tracy/TestScript
xmodlog.log
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ nl /home/tracy/TestScript/xmodlog.log
     1  default
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ rm /home/tracy/TestScript/xmodlog.log
rm: remove write-protected regular file '/home/tracy/TestScript/xmodlog.log'? y
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls /home/tracy/TestScript

Кроме того, ниже приведены две последние строки (по метке времени), показанные journalctl как до сна, так и после возобновления:

Последние две строчки перед сном

Последние две строки после резюме

      tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ journalctl -xe | grep 'sleep\|suspend'
Mar 09 21:30:21 tracy-HP17 sudo[132552]:    tracy : TTY=pts/0 ; PWD=/usr/lib/systemd/system-sleep ; USER=root ; COMMAND=./20xmodmap
Mar 09 21:37:40 tracy-HP17 sudo[132821]:    tracy : TTY=pts/0 ; PWD=/usr/lib/systemd/system-sleep ; USER=root ; COMMAND=./20xmodmap

Похоже, что скрипт не запускается при возобновлении работы, так как вывод из journalctl до и после идентичен....

Редактировать 6:

Хорошо, поэтому, основываясь на комментарии ниже от blitzter47, я углубился в то, что здесь происходит с точки зрения управления питанием. И, похоже, у меня были некоторые (неправильные) предубеждения относительно происходящего.

Во-первых, следуя указаниям в комментарии, выдача, а затем пробуждение системы выполняет скрипт, расположенный в , о чем свидетельствует создаваемый целевой файл, содержащий слово «post». Это произошло впервые (кроме выполнения скрипта из командной строки) (и я по понятным причинам взволнован тем, что этот прогресс был достигнут).

Итак, это заставило меня задаться вопросом, какая разница была в этой команде и в том, что я делал. И после прочтения статьи « Понимание приостановки » я считаю, что происходило то, что я достигал состояния S1, но что команда достигала состояния S3. Или, другими словами, я просто блокировал экран, но фактически не приостанавливал работу компьютера (за исключением случаев, когда машина не использовалась в течение длительного периода времени, о чем я расскажу через минуту).

Итак, я вернулся к тому, чего я на самом деле пытался достичь, а именно к тому, чтобы определенное сочетание клавиш сохранялось, когда система «приостанавливается». Ранее я отмечал, что в некоторых случаях сочетание клавиш сохранялось, когда я возвращался к компьютеру, а в некоторых случаях — нет, но я точно не понял, откуда это взялось. Ну, теперь я утверждаю, что времена, когда он выживал, были времена, когда система просто блокировала экран (т.е. достигала состояния S1), но фактически не приостанавливалась (т.е. не достигала состояния S3). В то время как в тех случаях, когда сочетание клавиш не сохранилось, машина фактически достигла подозрительного состояния (S3) — возможно, из-за того, что ее не трогали в течение более длительного периода времени.

Итак, суть в том, что system-sleep работает правильно для того, что я пытаюсь сделать (теперь, когда я действительно понимаю, что это такое). Итак, моим следующим шагом будет фактическое обновление сценария из Edit 5 (который работает правильно, когда я достигаю приостановки (т.е. состояния S3)) с помощью команды для восстановления моей комбинации клавиш, а затем посмотрите, есть ли ситуации, когда комбинация клавиш не выживает, тогда переоцените то, что происходит в этот момент.

Итак, учитывая все это, я собираюсь отметить исходный ответ blitzter47 как принятый, и если / когда я замечу, что мое сочетание клавиш не сохраняется в определенном состоянии, я опубликую новый вопрос с (надеюсь) лучшим представлением о какова основная причина.