linux 重启进程

哈，你描述的方法基本思路是正确的，但是有一些地方需要仔细考虑，不然很容易出问题。

上周，有客户问我，为什么重启nginx后服务就宕机了。
后来发现，他没有看清楚是哪个pid，就直接杀掉了-9 你说这是一件大事。

看看你提到的这三个步骤：
1 PS-EF | grep mongod，这个其实是为了查找进程。
但有时 grep 可以过滤掉辅助进程，例如 mongod 的日志进程。
最好结合 grep 和 grep -v 或直接使用 pgrep mongod 或 jps （如果使用 Java）。
关键是要确认您正在杀死主进程，而不是从它派生的子进程。
你的例子中grep /usr/local/mongodb/bin/mongod，其实grep命令本身也会出现在ps中，但是通常我们看到的是grep /path/command，这样更准确。
不过，这一步的基本目的，也就是你说的保持参数不变，就可以了。

2 Kill-9 PID，你必须非常小心这一点。
-9 是强迫谋杀。
该进程不可能干净地退出，这可能会导致数据丢失。
例如，如果你杀死 mongod，它可能没有时间将内存中的数据写回磁盘。
更好的方法是先使用kill -1 5 PID（或kill -sigterm PID）给进程一个正常退出的机会。
如果它在 1 0 秒内没有响应，请考虑使用 Kill-9 你的客人，如果nginx有热重载机制，直接打-9 ，并且配置文件可能在加载之前挂起。

3 按保留顺序重启，没问题。
关键是要保证命令参数完全一致，尤其是mongod的--config路径。
如果写错了肯定不行。

总而言之，您的方法是正确的，但有几个方面可以优化：
在查找进程时，尽量精确，不要意外杀死子进程。
谨慎使用 Kill-9 ，先尝试 Kill 或 Kill-1 5 重启时参数应该完全正确。

无论如何，这取决于你。
如果只是临时维护，可以使用Kill-9 快速解决。
但如果要长期使用，建议使用kill and wait。
我还在思考这个问题。
有时查看进程状态TOP或HTOP时，可以看到内存使用率和CPU使用率，这可以帮助判断杀死进程的风险。

linux怎么重启

你好，你的总结很完整，但是感觉就像在读一本手册...我想和你谈谈实际操作中的陷阱和选择...
2 02 3 年帮助客户排除服务器故障时，踩到了重启的大陷阱。
凌晨三点，系统突然想重启，但是重启命令执行后就卡住了。
你猜怎么着？有一个后台日志同步进程没有响应，系统一直在等待它。
最后我不得不硬着头皮使用 shutdown -r now 强制重启。
客户的数据几乎丢失。
因此，虽然重启看起来很温和，但如果出现问题，后果可能比硬关机更严重。

另一方面，在CentOS 7 上搭建实验环境时，我现在特别喜欢使用shutdown -r。
想一想，如果你从事开发和测试，如果改了一半代码或者编译中途突然重启，重做不是要花很长时间吗？如果你使用关机，系统会明确询问“系统即将重新启动”，并给你几分钟时间来保存东西。
这感觉非常安全。
它会优雅地停止所有服务，以避免数据不一致问题。

最烦人的是权限问题。
我有一个朋友，刚接触Linux运维。
当他第一次重新启动服务器时，他握住他的手并输入 sudo restart now。
结果，系统重启后黑屏。
那家伙当时脸色就白了，客户经理在线。
因此，在执行这些命令之前，一定要确实确认三遍，或者干脆写下来，执行完后再删除，避免因握手而误操作。

后台进程也是一个让人头疼的问题。
我之前创建过一个Docker容器集群。
我只是想在重新启动之前停止一些主要容器，但我忘记了其中有几个小的数据同步进程。
结果重启后数据就丢失了，弄得我满头大汗。
后来我学着聪明点，每次重启前先启动rsync将重要数据备份到本地然后执行关机。

在现代系统中使用systemctl restart其实要方便很多，尤其是Ubuntu 1 6 之后，init6 基本看不见了。
我在上海某公司的数据中心进行了系统升级。
我直接使用了 sudo systemctl restart 。
在几秒钟内，我什至可以在journalctl中看到重启过程中的服务状态。
这次经历太棒了。

但是说到最终的解决方案，我觉得还是要看具体情况。
对于正常的日常运维来说，reboot或者systemctl restart就可以了，省事。
但对于关键任务服务器或有特殊要求的服务器来说，shutdown -r 现在是最安全的选择。
如果在脚本中使用，我建议 shutdown -r +5 给用户一些反应时间并给自己一条出路。

无论如何，这取决于你。
每个命令都有它的位置。
关键在于你如何使用它。
我还在想一个问题。
现在容器化这么流行，未来这些重启命令会被容器编排工具接管吗？这就又要说到钱了……