“sudo stop”是否给 bash 一个书写历史的机会?

“sudo stop”是否给 bash 一个书写历史的机会?

我在一台不常访问的机器上进行了一些远程工作,在会话结束时,我发出sudo halt终止连接并关闭机器的命令。不幸的是,现在我不知道我在会话中使用的命令是否已写入文件.bash_history。根据man halt它向所有正在运行的进程发送一个 SIGTERM,然后发送一个 SIGKILL (我认为只有当进程没有及时终止时它才会这样做):

停止和重新启动实用程序将文件系统缓存刷新到磁盘,向所有正在运行的进程发送 SIGTERM(随后发送 SIGKILL),并分别停止或重新启动系统。

我在我的个人机器上测试了这一点,首先向 bash 发送 SIGTERM,但 bash 似乎没有响应。然后我发送了一个 SIGKILL,这显然迫使 bash 死掉。然后我检查了该.bash_history文件,看看是否在我的会话中写入了任何内容,但什么也没有。这对我来说是有意义的,因为根据我的理解,SIGTERM 可以被进程忽略,并且它可以根据需要执行其关闭过程,因为它可以解释如何响应此信号。然而,再次根据我自己的理解,SIGKILL可能不会被忽略,并且不会授予进程任何时间来执行清理或其他死亡仪式。

根据这次测试以及我从这次测试中得出的结论,看来当我sudo halt在远程主机上发出时我的远程会话被保存的可能性很小。有什么办法我可能会出错并且我的远程会话被保存到吗.bash_history

答案1

  • ssh 被 SIGTERM 杀死
  • ssh 关闭其伪终端 (pty) 主设备
  • pty 向 bash 发送 SIGHUP。
  • “shell 在收到 SIGHUP 后默认退出。”

https://stackoverflow.com/questions/5527405/where-is-sighup-from-sshd-forks-a-child-to-create-a-new-session-kill-this-chi

相关内容