使用PID文件杀死守护程序 [英] Killing a daemon using a PID file

查看:112
本文介绍了使用PID文件杀死守护程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

关于运行守护程序的常见Linux/UNIX习惯用法是生成守护程序,并创建一个仅包含守护进程的进程ID的PID文件.这样,要停止/重新启动守护程序,您只需拥有kill $(cat mydaemon.pid)

A common Linux/UNIX idiom when it comes to running daemons is to spawn the daemon, and create a PID file which just contains the process ID of the daemon. This way, to stop/restart the daemon you can simply have scripts which kill $(cat mydaemon.pid)

现在,这里存在很多不一致状态的机会.假设运行守护程序的计算机被强制关闭,然后重新启动.现在,您有了一个PID文件,该文件引用了一个不存在的进程.

Now, there's a lot of opportunity here for inconsistent state. Suppose the machine running the daemon is forcefully shut off, then restarted. Now you have a PID file which refers to a non-existent process.

好的,没问题...您的守护程序将尝试杀死不存在的进程,发现它不是真实进程,然后照常继续操作.

Okay, so no problem... your daemon will just try to kill the non-existent process, find that it's not a real process, and continue as usual.

但是...如果一个真实的过程-只是不是您的守护程序,该怎么办?如果这是其他人的流程或其他重要流程,该怎么办?您无法知道-杀死它有潜在危险.一种可能是检查进程的 name .当然,这也不是万无一失的,因为没有理由没有另一个进程可能具有相同的名称.尤其是,例如,如果您的守护进程在诸如Python之类的解释器下运行,则在这种情况下,进程名称将永远不会是唯一的东西-它只会是"python",在这种情况下,您可能会无意中杀死其他人的进程.

But... what if it is a real process - just not your daemon? What if it's someone else's process, or some other important process? You have no way of knowing - so killing it is potentially dangerous. One possibility would be to check the name of the process. Of course, this isn't foolproof either because there's no reason another process might not have the same name. Especially, if for example, your daemon runs under an interpreter, like Python, in which case the process name will never be something unique - it will simply be "python", in which case you might inadvertently kill someone else's process.

那么,如何处理需要重新启动守护程序的情况呢?我们怎么知道pid文件中的PID一定是守护程序?

So how can we handle a situation like this where we need to restart a daemon? How can we know the PID in the pid file necessarily is the daemon?

推荐答案

如果您确实想为用户提供脚本,则可以让守护进程自行管理其pidfile并添加atexitSIGABRT处理程序即使在不正常关机时也可以取消链接pidfile.

If you really want to provide a script for your users, you could the let the daemon process manage its pidfile on its own and add an atexit and a SIGABRT handler to unlink the pidfile even on unclean shutdown.

更多方法还包括将进程启动时间存储在pidfile中.与易失性存储(例如/var/run)一起使用,这是一种非常可靠的识别进程的方法.不过,这会使kill命令更加复杂.

More ways include also storing the process startup time in the pidfile. Together with volatile storage (e.g. /var/run) this is a pretty reliable way to identify a process. This makes the kill command a bit more complicated though.

但是,我个人认为守护程序开发人员不应该对此太在意,而应由目标平台管理守护程序的方式(系统化的,新贵的,好的SysV init脚本)来处理.这些通常具有更多的知识:例如systemd会很乐意接受根本不进行分叉的守护程序,从而使其可以直接监视其状态,而无需使用PID文件.然后,您可以为最常见的解决方案(当前可能是systemd,因为Debian也会迁移到它,因此也会很快在ubuntu上)提供配置文件,这些文件通常比完整的守护进程管理更容易编写.

However, I personally think that a daemon developer should not care (too much) about this and let this being handled by the target platforms way to manage daemons (systemd, upstart, good ol’ SysV init scripts). These have usually more knowledge: systemd for example will happily accept a daemon which does not fork at all, allowing it to monitor its status directly and without the requirement for a PID file. You could then provide configuration files for the most common solutions (currently probably systemd, given that Debian migrates to it too and it will thus also hit ubuntu soon), which are usually easier to write than a full fledged daemon process management.

这篇关于使用PID文件杀死守护程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆