☰

行为

tag-icon • tag-icon proc character-encoding
行为

我正在解析/proc/pid/cmdlineLinux 系统（Ubuntu 16.04）上的许多进程的值，并发现虽然大多数条目都是空编码的，正如预期的那样，至少有一个使用空格作为分隔符，这是我意想不到的。

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

行为

这是当我尝试为其中一个 chromium 浏览器进程捕获 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

答案1

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

不正确。

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

Chromium 会覆盖 a 之后的参数fork()，以便您在 的输出中看到一些有趣的内容ps。它正在使用setproctitle()库函数。这是 BSD C 库的一部分。它不是 GNU C 库的一部分。在 GNU C 平台上，Chromium 使用一个setproctitle()自己的直接覆盖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()为我的工具集编写了一个相当简单的函数来使用它。

外部的
空白
设置proargv（
    size_t argc，
    常量 char * argv[]
）{
#if 已定义(__FreeBSD__) ||定义(__DragonFly__)
    std::string s；
    for (size_t c(0); c < argc; ++c) {
        if (!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 |前景.暂停|
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) {
    if (!title.empty())
      标题+=“”；
    标题 += command_line->argv()[i];
  }
  // 如果我们自己在上面添加了 '-'，则禁用在 argv[0] 前面添加它。
  setproctitle(have_argv0 ? "-%s" : "%s", title.c_str());

如您所见，铬本身已经有新的参数向量作为一系列以 ␀ 结尾的字符串。它将它传递给一个中间库层，该层需要将它们全部打包成一个字符串，其中实际的系统调用级别仍然按照以 ␀ 结尾的字符串的参数向量进行操作。

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

也许你可以说服 Chromium 的作者采用类似的东西setprocargv()。 ☺

进一步阅读

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

相关内容