为了提高可追溯性、问责制等，我希望某些应用程序由 systemd 进行监督，并将其输出收集在日志中。我知道当我使用 systemd-run 的服务模式时，这一切都会自动发生，但由于对调用环境的依赖，这有时是不可能的。
我尝试过同时使用 systemd-run 和 systemd-cat，但遗憾的是它无法捕获单元元数据。我知道理论上我可以在env启动进程之前将环境变量转储到一个文件中，然后将其传递EnvironmentFile=给 systemd-run，但这似乎是一种黑客行为。如果执行环境中除了所需的变量之外还有其他数据（例如文件描述符），它也会失败，尽管这是一个相对罕见的需求，因为 shell 管道（最常见的共享文件描述符类型）通常可以替换为临时命名的管道或文件。
我并不是不愿意使用 hacky 方法；我只是想知道是否有一个“已知的好”替代品。
编辑：由于评论询问，我正在寻找的元数据字段是_SYSTEMD_UNIT、_SYSTEMD_SLICE等，以及_AUDIT_LOGINUID通常_CAP_EFFECTIVE为受监督进程收集的其他此类元数据。当我查看 podman/conmon 容器日志时，我发现这对于范围单元是可能的，尽管是sd_journal_sendv在范围单元内手动创建的，但它具有完整的元数据。我还检查了 的源代码，logger(1)它使用相同的函数，所以我假设 podman/conmon 的单元设置中有一些东西可以使日志建立与 systemd-run 不存在的相关性。
答案1
经过进一步的实验，我发现分层systemd-run --scope确实systemd-cat可以正确捕获元数据，除了某些边缘情况；我的测试范围太窄，并设法准确地达到这些目标。
详细来说，journald 处理传入消息的时间和 systemd 垃圾收集在作用域单元终止后清理作用域单元的时间之间可能存在竞争条件。
在我的测试中，如果我在这两个工具中包含一个运行时间较长的进程，或者在一次性命令的末尾添加一个睡眠，则日志条目会适当地丰富单元元数据等。但是，我必须使用 的“exec”形式systemd-cat，即传递要在--.管道不起作用。我尝试在 下打开一个 shell systemd-run --scope，执行命令，并将输出通过管道传输到 systemd-cat 中。尽管如此，尽管我在管道之后添加了睡眠以避免上述竞争条件，但创建的日记条目并未通过单元元数据进行丰富。