logger -t sshd 的日志没进入 ssh namespace：标签不会改变路由

服务已经设置 LogNamespace=ssh，它的日志能在对应 namespace 里查到；终端执行 logger -t sshd，消息却仍进入默认 journal。-t sshd 只设置消息标识，终端里的 logger 进程并没有因此进入那个服务的日志 namespace。

先分清消息标识和进程所在的空间

LogNamespace= 作用于 unit 启动的进程。systemd 通过挂载命名空间，把相关日志 Unix socket 的目录覆盖到该 unit 的视图中；这些进程写 syslog、原生日志接口或标准输出时，由对应的 journald 实例收集。

终端运行的 logger 使用自己看到的 socket。给它换一个标签，不会改变 socket 路径，也不会复制服务的挂载视图。即使标签与服务名相同，消息仍可能进入默认 namespace。

这项机制还会限制服务进程向宿主机传播挂载；需要在宿主机创建挂载点的服务，应先检查这个条件，不能只为整理日志直接添加 LogNamespace=。

查询时也要选对 namespace

LogNamespace= 和 journalctl --namespace= 从 systemd 245 引入。先核对本机版本与实际 unit 配置；没有指定 --namespace 的 journalctl 查询默认 namespace。

systemd --version
journalctl --namespace=ssh -t sshd -n 20 --no-pager
journalctl -t sshd -n 20 --no-pager

这里 -t sshd 是查询消息标识，与指定 namespace 是两个筛选条件。使用有权读取相应日志的账号；查询为空时，不能仅凭这一点认定服务没有写日志。

若要同时对照默认空间和指定空间，可以使用 --namespace=+ssh；--namespace='*' 会合并所有 namespace，星号应加引号以免被 shell 展开。合并查询扩大的是读取范围，不会移动已经存储的消息。

让新的 logger 调用进入指定空间

需要专门写一条验证消息时，可以在支持该功能的系统级 systemd 环境中，授权创建一个带属性的临时 unit。以下命令会启动进程并新增日志；执行前确认管理员权限、logger 的实际路径，以及所选 namespace 的配置和日志保留要求。

sudo systemd-run -p LogNamespace=ssh /usr/bin/logger -t sshd 'namespace-check'

这条调用的关键是新进程由设置了 LogNamespace=ssh 的 unit 启动。随后在该 namespace 中查询 namespace-check，并检查临时 unit 的实际执行结果；仅看到 systemd-run 接受请求，还不能说明 logger 已成功写入。

对长期运行的应用，应在它自己的 unit 和部署流程中配置并验收日志，而不是把终端标签当成路由规则。过去已经写入默认 journal 的记录会保留在原处；修改新进程的属性不会追溯迁移它们，也不需要通过 vacuum 或删除日志来让配置生效。