我在思考我的 run.py
脚本是否可以在两种不同的模式下运行。
当以 nohup 模式运行时:nohup python run.py &
,它会像完整日志输出模式一样运行。但在正常模式下 python run.py
,它会像抑制日志模式一样运行。因此,对于用户来说,这将是整洁和清晰的。
所以,我的问题是:我的可运行 Python 脚本如何知道自己是在 nohup 模式下运行还是正常模式下运行?
我在思考我的 run.py
脚本是否可以在两种不同的模式下运行。
当以 nohup 模式运行时:nohup python run.py &
,它会像完整日志输出模式一样运行。但在正常模式下 python run.py
,它会像抑制日志模式一样运行。因此,对于用户来说,这将是整洁和清晰的。
所以,我的问题是:我的可运行 Python 脚本如何知道自己是在 nohup 模式下运行还是正常模式下运行?
nohup
命令修改了它启动的进程的操作系统级信号处理。这不会反映在命令的参数中,但进程可以查询自身以检查安装了哪些操作或信号处理程序。以下是如何执行此操作的:
import signal
if signal.getsignal(signal.SIGHUP) == signal.SIG_DFL: # default action
print("No SIGHUP handler")
else:
print("In nohup mode")
这将适用于任何Unix系统,可能也适用于Windows(未经测试)。有其他方法可以设置信号处理程序,可以从shell或程序内部设置,但如果您只是想区分nohup
和正常调用,则此方法可以告诉您所需的所有信息。
SIG_DFL
更加健壮。在我的系统上,nohup
会将其设置为 SIG_IGN
,但是谁知道它在其他地方会做什么?主要问题是是否已覆盖默认处理程序(即无)。如果调用 shell 已使用 trap
安装了处理程序函数,则这是类似于 nohup
的情况,我的代码将注意到它。 - alexisnohup
的副作用,或者OP(可能是混淆了)在后台使用nohup
运行的示例,这不是一个要求(你可以在后台运行而不使用nohup
,而且nohup
并不严格要求你在后台运行作业,尽管在实践中很少有用)。 - tripleeenohup
用于将进程放到后台并记录日志。输出重定向和正常的后台处理已经内置于shell中,作为特殊语法。 - alexisSIG_IGN
之外的任何内容都会在 exec()
上重置(这是有道理的,因为无论哪个信号处理程序在子进程中都不会存在,并且您不希望有人使用外部设置的、可外部触发的信号处理程序运行您的进程)。 - Hasturkun
sys.argv
,if __name__ == '__main__': print(sys.argv)
,它只输出了['run.py']
,但在命令nohup python run.py
中的python
关键字之前没有任何输出。 - naughty foxnohup
将stdout重定向到文件,但脚本或命令行也经常这样做。检查stdout不是一种可靠的方法。 - alexis