linux – 模拟阻塞系统调用中的进程

概述我正在尝试测试在受控环境中难以重现的行为. 使用案例： Linux系统;通常是Redhat EL 5或6(我们刚刚开始使用RHEL 7和systemd,所以它目前已超出范围). 在某些情况下我需要重新启动服务.我们用来停止服务的脚本通常运行得很好;它将SIGTERM发送到进程,该进程旨在处理它;如果进程在超时(通常是几分钟)内没有处理SIGTERM,脚本会发送一个SIGKILL,然后等待几分钟. 我正在尝试测试在受控环境中难以重现的行为.

使用案例：
Linux系统;通常是Redhat EL 5或6(我们刚刚开始使用RHEL 7和systemd,所以它目前已超出范围).

在某些情况下我需要重新启动服务.我们用来停止服务的脚本通常运行得很好;它将SIGTERM发送到进程,该进程旨在处理它;如果进程在超时(通常是几分钟)内没有处理SIGTERM,脚本会发送一个SIGKILL,然后等待几分钟.

问题是：在某些(罕见)情况下,进程在SIGKILL之后不会退出;这通常发生在它严重停留在系统调用上时,可能是因为内核级问题(损坏的文件系统,或者没有工作的NFS文件系统,或者同样糟糕的需要手动干预的东西).

当脚本没有意识到“旧”进程实际上没有退出并且在旧的进程仍在运行时启动新进程时,出现了一个错误;我们正在通过一个更强大的锁定系统解决这个问题(所以至少新进程如果旧的运行时不会启动),但我发现很难测试整个系统,因为我还没有找到一种方法来模拟困难的过程.

所以,问题是：

即使作为特权用户,如何手动模拟在向其发送SIGKILL时不会退出的进程？

解决方法 如果您的流程在执行I / O时遇到问题,您可以通过以下方式模拟您的情况：

lvcreate -n lvtest -L 2G vgtestmkfs.ext3 -m0 /dev/vgtest/lvtestmount /dev/vgtest/lvtest /mntdmsetup suspend /dev/vgtest/lvtest && dd if=/dev/zero of=/mnt/file.img bs=1M count=2048 &

通过这种方式,dd进程将等待IO并且将忽略每个信号,我知道在最新的内核中,当进程在nfs文件系统上等待IO时,信号不会被忽略.

总结

以上是内存溢出为你收集整理的linux – 模拟阻塞系统调用中的进程全部内容，希望文章能够帮你解决linux – 模拟阻塞系统调用中的进程所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。