如何判断运行我的python脚本的终端是否已关闭?如果用户关闭终端,我想安全地结束我的python脚本。我可以使用处理程序捕获SIGHUP,但不能在脚本以sudo身份运行时捕获。当我用sudo启动脚本并关闭终端时,python脚本继续运行。
示例脚本:
import signal
import time
import sys
def handler(signum, frame):
fd = open ("tmp.txt", "a")
fd.write(str(signum) + " handled\n")
fd.close()
sys.exit(0)
signal.signal(signal.SIGHUP, handler)
signal.signal(signal.SIGINT, handler)
signal.signal(signal.SIGTERM, handler)
time.sleep(50)
有时,脚本会在以sudo身份运行时执行处理程序,但更常见的是它不会。在没有sudo的情况下运行时脚本总是写入文件。我在Raspberry Pi上运行它。我在LXTerminal和gnome-terminal中看到了相同的东西。此示例脚本将在50秒后结束,但我的冗长代码将在无限循环中运行
最终目标是在Raspberry Pi上安装一个.desktop启动器来进行蓝牙扫描并找到设备。蓝牙扫描需要sudo,因为它使用4.0 BLE。我不确定为什么bluez需要sudo,但确实如此。在pi上输入sudo时,它从不要求输入密码,这对我来说很好。问题是关闭终端后,扫描过程仍在运行。扫描是通过在终端中运行的python脚本完成的。
答案 0 :(得分:6)
sudo是为SIGHUP语义而设计的,当它是tty上某个其他进程的子进程时。在这种情况下,当父进程退出时,所有进程都从内核获得自己的SIGHUP。
xterm -e sudo cmd
直接在伪终端上运行sudo。这产生了与sudo期望的不同的SIGHUP语义。只有sudo从内核接收一个SIGHUP,并且没有中继它,因为它只是在它的子进程也有它自己的时候才会从内核获得一个SIGHUP(因为有些东西是sudo' s)父母(例如bash)确实)。
我reported the issue upstream,现在在sudo 1.8.15及以后标记为已修复。
xterm -e 'sudo ./sig-counter; true'
# or for uses that don't implicitly use a shell:
xterm -e sh -c 'sudo some-cmd; true'
如果您的-c
参数是单个命令,则bash通过执行它来进行优化。处理另一个命令(在这种情况下是微不足道的true
),让bash坚持并作为一个孩子运行sudo。我测试过,使用这种方法,当你关闭xterm时,sig-counter从内核中获取一个SIGHUP。 (对于任何其他终端仿真器,它应该是相同的。)
我已经对此进行了测试,它适用于bash和dash。源代码包括一个方便的花花公子信号接收 - 不退出程序,您可以通过它来查看它收到的所有信号。
本答案其余部分的某些部分可能略有不同步。在找出sudo作为控制过程与sudo作为shell差异的孩子之前,我经历了一些理论和测试方法。
POSIX says伪终端主端的close()
导致:" SIGHUP信号应发送到控制进程,如果有的话,从属端为伪终端是控制终端。"
close()
的POSIX措辞意味着只有一个处理过程将pty作为其控制终端。
当bash是pty的slave端的控制进程时,它会导致所有其他进程接收SIGHUP。这是sudo期待的语义。
ssh localhost
,然后中止与~.
的连接或终止您的ssh客户端。
$ ssh localhost
ssh$ sudo ~/.../sig-counter # without exec
# on session close: gets a SIGHUP and a SIGCONT from the kernel
$ ssh localhost
ssh$ exec sudo ~/src/experiments-sys/sig-counter
# on session close: gets only a SIGCONT SI_USER relayed from sudo
$ ssh -t localhost sudo ~/src/experiments-sys/sig-counter
# on session close: gets only a SIGCONT SI_USER relayed from sudo
$ xterm -e sudo ./sig-counter
# on close: gets only a SIGCONT SI_USER relayed from sudo
测试这个很棘手,因为xterm
在退出和关闭pty之前也会自己发送一个SIGHUP。其他终端仿真器(gnome-terminal,konsole)可能会也可能不会这样做。我不得不自己写一个信号测试程序,不仅仅是在第一次SIGHUP之后就死了。
除非xterm以root身份运行,否则它无法向sudo发送信号,因此sudo只能从内核获取信号。 (因为它是tty的控制过程,并且在sudo下运行的进程不是。)
sudo
手册页说:
除非命令在新的pty中运行, 除非由用户进程而不是内核发送,否则不会中继SIGHUP,SIGINT和SIGQUIT信号。否则, 命令将接收SIGINT 每次用户输入control-C时两次。
在我看来,喜欢sudo的SIGHUP的双信号避免逻辑是为了作为交互式shell的子项运行而设计的。当没有涉及交互式shell时(来自交互式shell的exec sudo
之后,或者第一个地方没有涉及shell),只有父进程(sudo)获得SIGHUP。
sudo的行为对SIGINT和SIGQUIT都有好处,即使在没有涉及shell的xterm中:在xterm中按^ C或^ \后,sig-counter
只接收一个SIGINT或SIGQUIT。 sudo
收到一个并且不会转发它。这两个过程都是si_code=SI_KERNEL
。
在Ubuntu 15.04上测试,sudo --version
:1.8.9p5。 xterm -v
:
的XTerm(312)。
###### No sudo
$ pkill sig-counter; xterm -e ./sig-counter &
$ strace -p $(pidof sig-counter)
Process 19446 attached
quit xterm (ctrl-left click -> quit)
rt_sigtimedwait(~[TERM RTMIN RT_1], {si_signo=SIGHUP, si_code=SI_USER, si_pid=19444, si_uid=1000}, NULL, 8) = 1 # from xterm
rt_sigtimedwait(~[TERM RTMIN RT_1], {si_signo=SIGHUP, si_code=SI_KERNEL}, NULL, 8) = 1 # from the kernel
rt_sigtimedwait(~[TERM RTMIN RT_1], {si_signo=SIGCONT, si_code=SI_KERNEL}, NULL, 8) = 18 # from the kernel
sig-counter is still running, because it only exits on SIGTERM
#### with sudo, attaching to sudo and sig-counter after the fact
# Then send SIGUSR1 to sudo
# Then quit xterm
$ sudo pkill sig-counter; xterm -e sudo ./sig-counter &
$ sudo strace -p 20398 # sudo's pid
restart_syscall(<... resuming interrupted call ...>) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=20540, si_uid=0} ---
write(7, "\n", 1) = 1 # FD 7 is the write end of a pipe. sudo's FD 6 is the other end. Some kind of deadlock-avoidance?
rt_sigreturn() = -1 EINTR (Interrupted system call)
poll([{fd=6, events=POLLIN}], 1, 4294967295) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\n", 1) = 1
kill(20399, SIGUSR1) = 0 ##### Passes it on to child
read(6, 0x7fff67d916ab, 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}], 1, 4294967295
####### close xterm
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
rt_sigreturn() = -1 EINTR (Interrupted system call)
--- SIGCONT {si_signo=SIGCONT, si_code=SI_KERNEL} --- ### sudo gets both SIGHUP and SIGCONT
write(7, "\22", 1) = 1
rt_sigreturn() = -1 EINTR (Interrupted system call)
poll([{fd=6, events=POLLIN}], 1, 4294967295) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\22", 1) = 1
kill(20399, SIGCONT) = 0 ## but only passes on SIGCONT
read(6, 0x7fff67d916ab, 1) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}], 1, 4294967295
## keeps running after xterm closes
$ sudo strace -p $(pidof sig-counter) # in another window
rt_sigtimedwait(~[RTMIN RT_1], {si_signo=SIGUSR1, si_code=SI_USER, si_pid=20398, si_uid=0}, NULL, 8) = 10
rt_sigtimedwait(~[RTMIN RT_1], {si_signo=SIGCONT, si_code=SI_USER, si_pid=20398, si_uid=0}, NULL, 8) = 18
## keeps running after xterm closes
在sudo
下运行的命令仅在xterm关闭时才会看到SIGCONT。
请注意,单击xterm标题栏上的窗口管理器的关闭按钮只会让xterm手动发送一个SIGHUP。通常这会导致xterm中的进程关闭,在这种情况下xterm将在此之后退出。同样,这只是xterm的行为。
这是bash
获取SIGHUP时所做的事情,产生sudo
期望的行为:
Process 26121 attached
wait4(-1, 0x7ffc9b8c78c0, WSTOPPED|WCONTINUED, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
--- SIGCONT {si_signo=SIGCONT, si_code=SI_KERNEL} ---
... write .bash history ...
kill(4294941137, SIGHUP) = -1 EPERM (Operation not permitted) # This is kill(-26159), which signals all processes in that process group
rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [CHLD], 8) = 0
ioctl(255, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [26121]) = -1 ENOTTY (Inappropriate ioctl for device) # tcsetpgrp()
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
setpgid(0, 26121) = -1 EPERM (Operation not permitted)
rt_sigaction(SIGHUP, {SIG_DFL, [], SA_RESTORER, 0x7f3b25ebf2f0}, {0x45dec0, [HUP INT ILL TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM XCPU XFSZ VTALRM SYS], SA_RESTORER, 0x7f3b25ebf2f0}, 8) = 0
kill(26121, SIGHUP) = 0 ## exit in a way that lets bash's parent see that SIGHUP killed it.
--- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=26121, si_uid=1000} ---
+++ killed by SIGHUP +++
我不确定这部分工作是否完成。由于kill
和tcsetpgrp()
都失败了,所以实际退出可能是诀窍,或者它在启动命令之前所做的事情。
我自己尝试尝试的第一次尝试是:
xterm -e sudo strace -o /dev/pts/11 sleep 60
(其中pts / 11是另一个终端。)sleep
在第一个SIGHUP之后退出,所以没有sudo的测试只显示xterm手动发送的SIGHUP。
SIG-counter.c中:
// sig-counter.c.
// http://stackoverflow.com/questions/32511170/terminate-sudo-python-script-when-the-terminal-closes
// gcc -Wall -Os -std=gnu11 sig-counter.c -o sig-counter
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#define min(x, y) ({ \
typeof(x) _min1 = (x); \
typeof(y) _min2 = (y); \
(void) (&_min1 == &_min2); \
_min1 < _min2 ? _min1 : _min2; })
int sigcounts[64];
static const int sigcount_size = sizeof(sigcounts)/sizeof(sigcounts[0]);
void handler(int sig_num)
{
sig_num = min(sig_num, sigcount_size);
sigcounts[sig_num]++;
}
int main(void)
{
sigset_t sigset;
sigfillset(&sigset);
// sigdelset(&sigset, SIGTERM);
if (sigprocmask(SIG_BLOCK, &sigset, NULL))
perror("sigprocmask: ");
const struct timespec timeout = { .tv_sec = 60 };
int sig;
do {
// synchronously receive signals, instead of installing a handler
siginfo_t siginfo;
int ret = sigtimedwait(&sigset, &siginfo, &timeout);
if (-1 == ret) {
if (errno == EAGAIN) break; // exit after 60 secs with no signals
else continue;
}
sig = siginfo.si_signo;
// switch(siginfo.si_code) {
// case SI_USER: // printf some stuff about the signal... just use strace
handler(sig);
} while (sig != SIGTERM );
//sigaction(handler, ...);
//sleep(60);
for (int i=0; i<sigcount_size ; i++) {
if (sigcounts[i]) {
printf("counts[%d] = %d\n", i, sigcounts[i]);
}
}
}
我对此的第一次尝试是perl,但是在信号处理程序返回后,安装信号处理程序并不会阻止perl退出SIGHUP。我看到xterm关闭之前就出现了这条消息。
cmd=perl\ -e\ \''use strict; use warnings; use sigtrap qw/handler signal_handler normal-signals/; sleep(60); sub signal_handler { print "Caught a signal $!"; }'\';
xterm -e "$cmd" &
显然perl信号处理相当复杂,因为perl必须defer them until it's not in the middle of something that doesn't do proper locking。
C中的Unix系统调用是&#34;默认&#34;进行系统编程的方法,以便消除任何可能的混淆。 strace通常是一种廉价的方法来避免实际编写日志/打印代码来玩游戏。 :P