/proc/<pid>/cmdline 的意外非空编码

Question

我正在解析/proc/pid/cmdline我的 Linux 系统 (Ubuntu 16.04) 上许多进程的值，并发现虽然大多数条目是空编码的，但正如预期的那样，至少有一个使用空格作为我发现意外的分隔符。

从proc(5) 的文档中，我没有看到任何迹象表明这应该发生。有没有我应该期望空格作为分隔符而不是空值的情况？如果是这样，我在哪里可以找到描述该行为的文档？

---

行为

这是我尝试为铬浏览器进程之一捕获 cmdline 时看到的内容（请注意，空格字符用于分隔值）：

user@host:~$ cat /proc/2721/cmdline
/usr/lib/chromium-browser/chromium-browser --type=gpu-process --field-trial-handle=2073283832741738928,4790986738309707242,131072 --gpu-preferences=GAAAAAAAAAAAAQAAAQAAAAAAAAAAAGAA --gpu-vendor-id=0x15ad --gpu-device-id=0x0405 --gpu-driver-vendor=Mesa --gpu-driver-version=17.2.8 --gpu-driver-date --service-request-channel-token=3778166CAD6E96F44A7268DF1AB1DD53

我希望看到这样的事情（空值作为分隔符），这是我不从系统上的其他进程看：

 ~$ cat /proc/354/cmdline
vmware-vmblock-fuse/run/vmblock-fuse-orw,subtype=vmware-vmblock,default_permissions,allow_other,dev,suid

Answer 1

至少一个使用空格作为分隔符

不正确。

如果您查看 FreeBSD/TrueOS 上伪文件的末尾，您会遇到与 Chromium 完全相同的行为，您会发现一个␀. 这是␀ 终止的。这都是一个单一的论点。

Chromium 在 a 之后覆盖其参数fork()，以便在ps. 它正在使用setproctitle()库函数。这是 BSD C 库的一部分。它不是 GNU C 库的一部分。在 GNU C 平台上，Chromium 使用自己的asetproctitle()argv直接覆盖数据。

setproctitle()实际上不是这项工作的正确工具，因为它不允许设置多个参数字符串。它将格式化的“标题”设置为第 0 个参数并将参数计数设置为 1。所有内容都通过库函数作为一个参数进行编组。

这不是setproctitle(). FreeBSD/OpenBSD/NetBSD C 库版本也有任意的 2KiB 限制，直接继承自旧的 BSDsendmail程序（在 FreeBSD 情况下，库函数最初是从该程序中提取的），这对于 Chromium 经常设置的命令行来说太短了到。Chromium 自己的和 FreeBSD/OpenBSD/NetBSD C 库版本都有额外的功能，格式字符串是一个空指针，Chromium 不使用（但具有讽刺意味的是，仍然必须在自己的setproctitle()实现中处理）。

用更少的代码可以做得更好。在底层系统调用在FreeBSD / TrueOS的库函数调用来完成工作一旦构建参数数据，是sysctl()功能，同时CTL_KERN，KERN_PROC，KERN_PROC_ARGS，和一个进程ID作为地址。这可以接受多个以␀ 结尾的字符串。我setprocargv()为我的工具集编写了一个相当简单的函数来使用它。

外部的
空白
setprocargv (
    size_t argc，
    const char * argv[]
){
#if 已定义(__FreeBSD__) || 定义（__DragonFly__）
    std::string s;
    for (size_t c(0); c < argc; ++c) {
        如果 (!argv[c]) 中断；
        s += argv[c];
        s += '\0';
    }
    const int oid[4] = { CTL_KERN, KERN_PROC, KERN_PROC_ARGS, getpid() };
    sysctl(oid, sizeof oid/sizeof *oid, 0, 0, s.data(), s.length());
#elif 已定义(__OpenBSD__) ...

（OpenBSD/NetBSD 以 FreeBSD/TrueOS 过去的旧方式做事，ps_strings在应用程序内存中有一个结构，但它仍然sysctl()是使用的底层系统调用，以找到该结构的位置。）

% /package/admin/nosh/command/exec 前台暂停\; 真的 ＆
[1] 30318
% hexdump -C /proc/30318/cmdline
00000000 66 6f 72 65 67 72 6f 75 6e 64 00 70 61 75 73 65 |foreground.pause|
00000010 00 3b 00 74 72 75 65 00 |.;.true.|
00000018
% hexdump -C /proc/30319/cmdline
00000000 70 61 75 73 65 00 |暂停。|
00000006
%

因为setproctitle()是错误的工作工具，Chromium 正在使用新argv成员并构造一个由 ␠ 分隔的长字符串，作为单个参数传递给setproctitle().

  for (size_t i = 1; i < command_line->argv().size(); ++i) {
    如果 (!title.empty())
      标题 += " ";
    title += command_line->argv()[i];
  }
  // 如果我们在上面自己预先添加了 argv[0]，则禁用带有 '-' 的前缀。
  setproctitle(have_argv0 ? "-%s" : "%s", title.c_str());

如您所见，Chromium本身已经将新的参数向量作为一系列以␀ 结尾的字符串。它通过一个中间库层传递它，该层需要将它们全部聚集成一个字符串，而实际的系统调用级别仍然根据 ␀ 终止的字符串的参数向量进行操作。

因此，您所看到的行为是，Chromium 将其更改后的参数向量作为一个单独的参数呈现给系统。

也许您可以说服 Chromium 的作者采用类似setprocargv(). ☺

进一步阅读

• 彼得·韦姆 (1995-12-16)。setproctitle. FreeBSD 库函数手册。FreeBSD。