我试图跟踪问题出在哪里，但是我不知道在哪里找到输出（或如何配置systemd以将输出放置在某处）。
这是我的服务文件：
[Unit]
Description=Syncs files with a server when they change
Wants=network.target
After=network.target
[Service]
ExecStart=/usr/local/bin/filesync-client --port 2500
WorkingDirectory=/usr/local/lib/node_modules/filesync-client
Restart=always
[Install]
WantedBy=multi-user.target
在整个应用程序中，我输出到stdout和stderr。
我该如何读取守护程序的输出吗？
编辑：
我发现
man systemd.exec，其中提到了StandardOutput=选项，但是我不确定如何使用它。从手册页：StandardOutput= 控制已执行进程的文件描述符1（STDOUT）所连接的位置。继承，null，tty，syslog，kmsg，kmsg +控制台，syslog +控制台或套接字之一。
如果设置为继承，则将标准输入的文件描述符复制为标准输出。如果设置为null，则标准输出将连接到
/dev/null，即写入其中的所有内容都会丢失。如果设置为tty，则标准输出将连接到tty（通过TTYPath=进行配置，请参见下文）。如果将TTY用于输出，则仅执行的过程将不会成为终端的控制过程，也不会失败或等待其他过程释放终端。 syslog将标准输出连接到syslog（3）系统记录器。 kmsg将其与内核日志缓冲区连接，该缓冲区可通过dmesg（1）访问。 syslog + console和kmsg + console的工作原理类似，但也将输出复制到系统控制台。 socket通过套接字激活将标准输出连接到套接字，其语义类似于StandardInput=的相应选项。此设置默认为继承。这是否意味着这些是我唯一的选择？例如，我想将输出放在
/dev/shm之类的东西中。我想我可以使用Unix域套接字并编写一个简单的侦听器，但这似乎有点不必要。我只需要进行调试，最终可能会删除大多数日志并将输出更改为syslog。
#1 楼
更新正如mikemaccana所指出的那样，systemd日志现在是大多数发行版的标准日志记录设备。
要查看系统化单元的
stdout和stderr，请使用journalctl命令。sudo journalctl -u [unit]
原始答案
默认情况下，
stdout和将systemd单元的stderr发送到syslog。 如果您使用完整的systemd，则可以通过
journalctl来访问。在Fedora上，应该为
/var/log/messages，但是系统日志会将其放在您的规则中。 由于发布日期的影响，并且假设大多数与systemd接触的人都是通过fedora进行的，因此您可能受到了此处描述的错误的攻击：
https：//bugzilla.redhat .com / show_bug.cgi？id = 754938
它也很好地解释了它如何工作=）（这是selinux-policy中的一个错误，导致未记录错误消息，并已在
selinux-policy-3.10.0-58.fc16中修复）评论
请注意，使用这样的标准日志记录机制默认情况下不会创建持久日志。为此，您需要创建/ var / log / journal，然后运行sudo systemctl restart systemd-journald
– mlissner
15年5月8日在2:21
什么系统日志功能和优先级？
– jrwren
2015年7月7日在16:31
这对我有用：在我的单元的所有输出都出现在journalctl中之后，StandardOutput = syslog + console和StandardError = syslog + console。默认设置显然是错误的。 （例如/etc/systemd/system.conf中的DefaultStandardOutput）
– gregn3
15年7月22日在12:23
-f对我有帮助。发生更改时跟踪日志（用例跟踪作为守护程序运行的minecraft服务器）
– Blaughw
16年11月21日在4:55
这让我发疯……在标准的Debian Stretch Journalctl上，我什么也看不到。我什至使用/ usr / bin / stdbuf -oL
– jlh
18/12/18在9:14
#2 楼
更简短，更简单的非遗留答案：sudo journalctl -u [unitfile]
其中[unitfile]是系统的
.service名称。例如，要查看来自myapp.service的消息，sudo journalctl --unit=myapp
要实时跟踪日志：
sudo journalctl -f -u myapp
评论
请注意，如果收到“找不到日志文件”错误，则可能必须使用sudo。
–bigjosh
2015年11月17日15:51
syslog不是旧版...
–Miles Rout
16年6月26日在5:18
它在当前的Linux发行版中。您可能真的很喜欢syslog，但这并不会改变它们附带的内容。
–mikemaccana
16-6-26在11:13
当然。并且它也使用syslog。我的意思不是说未使用systemd，而是syslog不是旧版。
–迷宫
17 Mar 10 '17 at 16:46
@JECompton如果当前Linux发行版上的所有日志记录均使用日志记录，并且不需要syslog且仅用于兼容性，则从逻辑上讲，syslog是旧的。
–mikemaccana
17年3月13日在11:27
评论
您是否尝试过检查/ var / log / syslog的输出？大多数系统会将内容登录到/ var / log /中，因此我将从此处进行检查开始。如果知道输出，则可以使用grep搜索文本：grep“ my output” / var / log应该可以解决问题。@ sbtkd85-好吧，我没有/ var / log / syslog，但是/ var / log / messages可以解决问题。问题是，根据日志，问题是我的守护程序在启动时崩溃，但是我可以告诉它它仍在运行，因为它具有HTTP服务器，并且可以查询它。看来其余的日志已经丢失了...
为什么不尝试设置StandardOutput = tty，以便在启动守护程序时可以看到发生了什么。它应该输出终端（您可能必须使用ttyS0或类似的东西才能在屏幕上显示输出）。
标准IO重定向运算符不应该在这种情况下工作。类似于ExecStart = / usr / local / bin / filesync-client --port 2500 2> /tmp/filesync.log
实际上是在滥用CPU？是systemd，您的服务还是系统（例如，由于systemd变得疯狂而通过生成服务的新副本）？