过程的连续线在过程的生命周期内应该是恒定的吗？

Question

在基于linux的(基于unix的)系统中，所有进程都有所谓的cmdline。在生命周期内改变它可以吗？在前面的示例中，使用一些进度/调试信息修改cmdline。

是否对使用进程cmdline有任何限制/约定？

我为什么要问？在out项目中，为了监视特定的子系统，我们广泛使用了修改cmdline的方法。对于读取cmdlines，我们使用python库psutil。但是从某些版本中，这个实用程序开始缓存进程的cmdline。我已经创建了一个bug，但是其中一个作者声称，cmdline不应该在进程的生命周期(链接到bug)中被更改。

有什么建议吗？

谢谢。

在“更改”下更新cmdline --我没有想到更改进程的exec参数。我曾在明朝更名(http://www.unix.com/man-page/FreeBSD/3/setproctitle/)

Answer 1

只有一种情况下，我会重命名命令的进程，在使用#!'d子进程运行脚本的情况下，很难用killall快速找到它。

其中一个例子是运行一个名为'foobar‘的Python脚本，它是#!'d，如下所示：

#!/usr/bin/python

...

它将在ps中显示为

   0 18852 18810   0  1:09AM ttys006    0:03.50 /usr/bin/python -B ./foobar

在这种情况下，重命名过程是有益的，因为它将与执行者的期望相匹配，如果事情变得疯狂，您可以快速地发出一个killall，而不必拿出放大镜。当我想要一个过程结束的时候，我希望它死掉。

但是，在重命名线程的情况下呢？我用芹菜碰到它，发现它是无谓的，没有必要地“聪明”。我建议不要这样做。关于查找线程状态是有用的论点是没有意义的，因为枚举进程和查看每个人的proc结构中提取一点点状态信息的成本比将其登录到syslog或stdout/err要昂贵得多。

在您在Linux上并通过/proc文件系统进行枚举的情况下，我可以想象它的成本会更高。

你不应该改变它的论点，因为你“失去”了关于程序是如何启动的信息。我并不完全同意这一点，因为至少在Linux中，/proc//cmdline的缺省限制是4096，而且进程参数的最大长度大约是1024*1024字节。(想想: ls -l /dir/with/100_1000_files/*)

因此，您没有真正的保证有‘真正的’cmdline，不应该期望它在那里。

Answer 2

我必须同意那个声称不应该改变的人。命令行是程序调用方作为参数提供给您的内容。你在这件事上胡闹是不明智的。

如果您希望为您的子进程提供不同的命令行参数，则需要“执行”它们。我不知道这是不是你所说的“工人”的意思，你的问题在概念上有点模糊。

如果您解释了您的需求是什么(详细地)，而不是您如何实现该需求，这可能会有所帮助。

Answer 3

对于进程来说，唯一不改变的是进程id。除此之外，任何事情都可以改变。例如，如果进程执行exec系统调用，则代码和数据段以及命令行都会发生变化。

所有的缓存系统都提高了速度，但一些数据必须实时改变，系统逻辑(包括缓存)必须满足它的需要。