我的日志有问题journalctl，它没有显示超过一小时的日志。
第一个日志条目大约是一小时前，而不是要求的 2 天前。
$ date -u
Wed May 13 08:59:21 UTC 2020
$ sudo journalctl --utc --since="2 days ago" -n 1 --no-pager -u datalake-profile-table-error-worker@1.service
-- Logs begin at Tue 2020-03-17 17:30:22 UTC, end at Wed 2020-05-13 09:00:10 UTC. --
May 13 08:11:03 <log content>
服务已于 5 天前开通：
$ sudo systemctl status datalake-profile-table-error-worker@1.service
...
Active: active (running) since Thu 2020-05-07 15:45:47 CEST; 5 days ago
...
jorunalctd.conf不过看起来并不可疑：
$ cat /etc/systemd/journald.conf
# This file is part of systemd. …使用 Ubuntu 21.04、GNOME 3.38.5 Wayland 和 zsh 作为我的 shell，
$ systemctl --user show-environment
PATH=/home/tony/.cargo/bin:/home/tony/.cargo/bin:/home/tony/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
我想知道如何~/.cargo/bin重复三遍，但找不到一处设置它的地方。 ~/.pam_environment根本没有提到“PATH”，而且我从来没有运行过 rust 工具链sudo，所以这个变量不太可能在位于/etc.
如何跟踪 PATH 环境变量的设置？
我有一台 24/7 开启的笔记本电脑，它运行 debian，没有窗口系统（只有 tty）。我浏览了各种推荐 setterm 或 vbetool 的帖子，并且尝试制作 systemd 启动脚本，但这不起作用。这些方法也不适用于 ssh。
如何在启动时关闭笔记本电脑的屏幕？或者ssh？
（关闭盖子并修改 /etc/systemd/logind.conf 不起作用，因为如果我然后通过 ssh 重新启动它，它不会再次启动，因为 BIOS 会将其置于睡眠模式，我无法更改BIOS 中的此行为）
编辑：如果这是一个关键细节，我很抱歉，但我完全忘记说我已将 nomodeset 添加到/etc/default/grub.
我有一个较旧的 initd 脚本来启动我的应用程序。它在旧版本的 SuSE 下运行良好，但在 Open SuSE 12.3 上失败。
奇怪的是
cd /etc/init.d ; ./script start
工作正常。
/etc/init.d/script start
显示重定向到 systemctl，但不启动我的应用程序（也不显示 initd 脚本的任何输出）。
我没有看到任何日志条目显示出了什么问题。我看到的唯一条目是在 /var/log/messages 中，说明应用程序已启动。
我该如何调试？
我已经阅读了一些关于 systemd 的内容，但仍然无法弄清楚如何使用它gpg-agent在登录时自动启动。我认为我会使用systemctl --user，但构建 使gpg-agent.service我难倒。欢迎任何和所有指针。
我正在迁移绑定到块设备的更改操作并运行给定脚本的现有 udev 规则。
SUBSYSTEM=="block", ENV{DEVNAME}=="/dev/sr0", ACTION=="change", RUN+="/usr/local/bin/script"
在此配置中，udev 传递了与硬件设备相关的环境变量，例如ID_CDROM_MEDIA-0和ID_FS_LABEL。我已经更新了 udev 规则以使用 systemd 在硬件更改时启动服务。
SUBSYSTEM=="block", ENV{DEVNAME}=="/dev/sr0", ACTION=="change", TAG+="systemd", ENV{SYSTEMD_WANTS}=="drive-change.service"
systemd 服务文件：
[Unit]
Description=changes to dvd drive
[Service]
Type=oneshot
ExecStart=/usr/local/bin/script
[Install]
WantedBy=multi-user.target
此时服务在更改事件上运行，但 udev 中 RUN 命令传递的环境变量不会传递给服务的执行。
是否可以将环境从 udev 传递到 systemd 的执行环境，还是需要显式传递参数？
我正在尝试在我的 Ubuntu 15.04 中启动 ddclient 作为守护程序，它现在使用systemd，但甚至无法在https://help.ubuntu.com/community/DynamicDNS上关注 Ubuntu wiki 。
我弄完了，
update-rc.d ddclient defaults
然后尝试，
invoke-rc.d ddclient start
进而，
service ddclient start
但ps上市仍ddclient遥遥无期。
只有在我做了之后，
/etc/init.d/ddclient restart
我开始看到ddclient出现在ps列表中。
不/etc/init.d/ddclient restart应该被弃用吗？我们不应该使用invoke-rc.d ... start或service ... start代替吗？
在 Ubuntu 15.04 systemd 下启动 ddclient 作为守护进程的正确方法是什么？
使它始终在机器启动时启动的正确方法是什么？我想update-rc.d它将不再工作，因为invoke-rc.d，对吧？
谢谢
我有一个带有 LUKS 加密分区的外部驱动器。由于该设备是外部 USB 设备，我并不总是需要它，我只想按需解密和自动挂载。我可以轻松地使用x-systemd.automountin将文件系统自动挂载到解密分区上/etc/fstab。但是，我无法按需解密分区。我尝试了两种不同的方法：
我添加了该行
mnt-usb-crypt UUID=<UUID> /path/to/keyfile luks
到/etc/crypttab。但是，现在分区总是被解密，即使我没有在/etc/fstab.
我更改/etc/crypttab并添加了noauto选项：
mnt-usb-crypt UUID=<UUID> /path/to/keyfile luks,noauto
现在，根本没有 systemd 设备，预期dev-mapper-mnt-usb.device不存在。
根据 的联机帮助页crypttab，没有像x-systemd.automountcrypt 设备这样的选项。
是否有可能将 systemd 配置为仅在访问设备时对其进行解密？
当我尝试关闭logind会话（通过注销）时，某些进程仍在会话下运行，从而阻止其正确终止，从而导致也user@uid.service未终止。我听说后者是一种预期行为（某些单元保持运行是可取的），但我认为让会话运行不是实现这一目标的正确方法。此外，当我手动终止会话时，user@uid.service也终止，所以它似乎像挥之不去的会话被用于此目的。
为了说明我在做什么，这是systemd-cgls我正常登录时（即现在）的输出的一部分：
Control group /:
-.slice
??user.slice
??user-1000.slice
??user@1000.service
? ?? //various units listed; removed for brevity
??session-c8.scope
??4883 login -- sammko
??4905 /usr/bin/gnome-keyring-daemon --daemonize --login
?? //various other processes listed; removed for brevity
输出完全符合预期。退出会话后：
Control group /:
-.slice
??user.slice
??user-1000.slice
??user@1000.service
? ?? //various units listed; removed for brevity
??session-c8.scope
??4905 /usr/bin/gnome-keyring-daemon --daemonize --login
gnome-keyring-daemon以某种方式幸存下来，使会话保持活跃。如果我们现在运行loginctl show-session c8，我们会State=closing在输出中找到。如果我们继续，kill -HUP 4905我们会发现进程和会话终止，并带走了整个进程user-uid.slice。如果我们继续kill …
我的公司设置了一些它开发的软件，在旧版本的 SLES 上使用 init.d 作为服务运行。我们最近开始在 Amazon 的 EC2 中的 SLES 12 实例上设置新环境，并发现 SLES 12 现在使用 systemd 而不是 init.d。然而，init.d 脚本（即 /etc/init.d 中）中定义的服务似乎仍然可以正常启动，因为 systemd 在后台执行一些魔法来处理预先存在的 init.d 脚本，这很棒。
但是，我们不想以 root 用户身份运行我们的服务——而是创建一个新用户来运行我们的服务。问题是，当我们尝试以非 root 用户身份启动我们的服务时，无论 systemd 为运行旧的 init.d 服务做任何准备，都会请求 root 身份验证，我们认为这不是必要的。在较旧的 SLES 环境中（使用实际的 init.d），我们可以毫无问题地以非 root 用户身份启动服务。据我所知，我们的非 root 用户权限和文件所有权在两种环境中都是相同的。
我认为这是 systemd 对旧的 init.d 内容进行后台处理的原因是启动我们服务的脚本在启动/停止服务的实际命令之前立即回显一行文本，但该行不是't output 即我们被要求在 echo 语句之前进行 root 身份验证。隐藏在 systemd 中的某个包/模块需要身份验证，但我现在不记得它的名字了。
请注意，如果可能，我们希望避免为我们的服务创建特定于服务的 .service 文件 - 我们希望坚持使用我们拥有的 init.d 脚本，并以非 root 用户身份运行它。此外，我们希望在不使用 sudo 的情况下运行该服务（我们在旧环境中不需要 sudo）。
对于这个问题缺乏细节表示歉意 - 一旦我回到办公室并可以获取具体细节等，我会用更具体的细节更新它。但这似乎可能是一个常见问题，所以我希望有人可以对此有所了解。
具体来说：我们希望在 SLES 12 上使用 systemd 以非 root 用户身份运行使用旧 init.d …