Ubuntu 20.04
我已经对从挂起恢复执行脚本或命令的方法进行了多次搜索，并提出了几种不同的方法来执行此操作，例如此处描述的方法- 没有一个对我有用。
我发现的第一个方法是使用 pm-utils。显然，从 15.04 左右开始，此方法已从 Ubuntu中删除
我发现的下一件事是使用systemd/system-sleep - 这对我也不起作用。我尝试在 /usr/lib/systemd/system-sleep 目录中创建一个脚本，还尝试了 /lib/systemd/system-sleep 目录（它显然链接到 /usr/lib/systemd/system-sleep 作为更改一个出现在另一个中）。我还尝试修改已经存在的脚本，称为 hdparm - 这也不起作用（我所做的修改是，touch /tmp/xmodlog.log但文件从未出现）。
那么，有人能告诉我在恢复时运行脚本或命令的正确方法是什么吗？
感谢任何输入/建议/网站 - 特别是那些对沿途发生的事情有详细说明和解释的网站......
编辑：
根据 Matigo 提供的答案，我做了以下事情：
在 /etc/pm/sleep.d 中，我创建了一个名为 00xmodkey.sh 的脚本。我将以下脚本代码添加到此文件中，然后确保它由 root 拥有，并且具有执行权限。
脚本内容（尝试 sh 和 bash 作为 shell）：
#!/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 的响应，我在/lib/systemd/system-sleep/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：
根据下面的评论，我将脚本更改为显式路径命令，并使用touch而不是echo. 结果没有变化。还尝试移动临时文件的位置，以确保它不会因为使用而发生奇怪的事情/tmp，但同样没有变化。这是修改后的脚本：
#!/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
简历后的最后两行
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 下面的评论，我从电源管理的角度深入研究了这里发生的一切。看起来我对正在发生的事情有一些（不正确的）先入之见。
首先，按照注释中的引导，发出sudo systemctl suspend然后唤醒系统确实会执行位于 中的脚本/lib/systemd/system-sleep，如正在创建的目标文件中包含“post”一词所示。这是第一次（除了从命令行执行脚本）发生这种情况（我很高兴正在取得这一进展）。
所以，这让我想知道那个命令有什么不同，以及我一直在做什么。在阅读了解挂起的文章后，我相信发生的事情是我正在达到 S1 状态，但sudo systemctl suspend命令正在达到 S3 状态。或者，换一种说法，我只是锁定了屏幕，并没有真正暂停计算机（除非机器长时间无人看管，我将在稍后谈到）。
因此，我回顾了我实际尝试完成的任务——即在系统“暂停”时使特定的键盘快捷键继续存在。我之前注意到，当我回到计算机时，键盘快捷键在某些情况下会保留下来，而在某些情况下则不会，但我并没有弄清楚它的确切来源。好吧，我现在假设它存活的时间是系统只是锁定屏幕（即达到 S1 状态）但实际上并没有挂起（即没有达到 S3 状态）的时间。虽然键盘快捷键无法生存，但机器实际上已经达到了可疑 (S3) 状态——可能是因为长时间不受干扰。
因此，底线似乎是 system-sleep对于我正在尝试做的事情确实可以正常工作（现在我真的明白那是什么了）。因此，我的下一步将是使用命令从 Edit 5（当我达到挂起（即 S3 状态）时正常工作）实际更新脚本以恢复我的键盘快捷键，然后查看是否存在键盘快捷键的情况无法生存，然后重新评估当时正在发生的事情。
因此，鉴于所有这些，我将blitzter47 的原始答案标记为已接受，并且如果/当我注意到我的键盘快捷键无法在特定状态下存活时，我将发布一个新问题（希望）更好地了解根本原因是什么。
