![捕捉神秘过程的最佳策略是什么?](https://linux22.com/image/22485/%E6%8D%95%E6%8D%89%E7%A5%9E%E7%A7%98%E8%BF%87%E7%A8%8B%E7%9A%84%E6%9C%80%E4%BD%B3%E7%AD%96%E7%95%A5%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F.png)
我的服务器上正在运行的进程每天晚上都会在午夜被杀死。它正在工作,发生时我不在场,而且我没有远程访问权限。
杀戮发生在每天晚上 23 点 59 分非常有规律。我知道这一点是因为当我第二天到达时:
- 处理截止时间为 23:59
- 该进程的日志显示最后修改时间为 23:59(并且新的日期日志将在之后立即开始)。
由于杀戮发生在同一时间,我强烈怀疑是批处理作业。我检查了crontab
我们所有机器的 s,但没有找到任何东西。显然我错过了一些东西。
我正在考虑制定一个监视脚本,该脚本将间歇性地报告输出,在几分钟前ps
启动并循环一段时间。at
这个想法似乎很弱并且很容易出错,所以我想知道是否有人有更好的想法。
更多细节:
宇宙是一个非常大、非常古老的遗留系统;我的团队中似乎没有人知道这样一个过程(如果有人知道,她就会加入我们的团队)尽管较大的组织由数千名员工组成,但理论上他们中的很多人都可以访问此过程(我不认为为什么他们会这样做)。换句话说,安全措施不是很严格。
环境由多台运行 Solaris 10 的计算机组成。
这不是生产环境,因此超时或停机时间并不重要。
我并不排除杀戮可能不是由于批处理作业造成的可能性,尽管由于计时的准确性而不太可能。
显然,我们的簿记工作存在缺陷,因此任何可以想象的事情都有可能发生。
我的问题是采取的最佳策略是什么?它属于“在遗留系统上工作的乐趣”的更大保护伞。我正在开始编写我的脚本,我将很快将其发布到此处以获取反馈。同时,如果有人有更好的想法,请说出来。
答案1
定期轮换日志很常见,在午夜轮换日志很常见。许多应用程序会自动执行此操作。
对于那些没有的人来说,有类似的工具logrotate
可以进行轮换。许多程序都配置为在发送 HUP 信号时重新打开其日志,这是logrotate
.
需要检查的事项:
- 所有的PID都改变了吗?如果没有,那么程序可能会轮换它们自己的日志,或者对其日志轮换做出适当的响应。
- 对于更改 PID 的程序,它们是否在午夜重新启动?如果没有,请检查他们的父母,看看它做了什么。
- 检查 root 的 crontab 以查看一天结束时运行的进程。
- 检查 crontab 中的进程用户 ID,以查看当天结束时运行的进程。
- 检查日志文件是直接写入还是由轮转日志的日志写入器写入。