我明白你在从SysV迁移到systemd时遇到的日志输出困扰——直接跑脚本有控制台输出，但用systemctl start启动就只能在journal里找，确实挺烦人的。下面给你分场景说几个可行的解决方案：

一、临时让输出直接到终端（无需修改单元文件） #

如果你只是偶尔需要在启动时看到实时输出，可以用systemctl run代替systemctl start，它会临时创建一个单元并把输出继承到当前终端：

systemctl run --unit=scriptA.service --standard-output=inherit --standard-error=inherit /path/to/scriptA

这个命令会直接把脚本的stdout/stderr打到你当前的终端窗口里，和直接执行脚本的效果一致。

二、修改单元文件永久生效 #

如果你想每次用systemctl start都能看到输出，需要调整你的.service单元文件配置，但这里要分两种情况：

情况1：你的脚本是前台运行服务（不会fork后台进程） #

修改你的单元文件（比如/etc/systemd/system/scriptA.service）：

[Unit]
Description=Script A Service

[Service]
# 确保Type设为simple或exec，对应前台运行的服务
Type=simple
ExecStart=/path/to/scriptA
# 让服务继承当前终端的输出流
StandardOutput=inherit
StandardError=inherit
# 可选：如果希望启动时阻塞等待脚本执行完成（比如脚本是一次性任务），可以加下面这行
# RemainAfterExit=no

保存后重新加载systemd配置：

systemctl daemon-reload

之后用systemctl start scriptA.service启动，就能在终端看到实时输出了。

情况2：你的脚本会fork后台进程（比如用&启动服务） #

这种情况下，StandardOutput的配置只能影响脚本本身的输出，后台子进程的输出还是会被systemd捕获到journal里。这时候你有两个选择：

1. 修改脚本让服务前台运行：去掉脚本里把进程放后台的&，让服务一直占着前台，这样systemd就能把输出转发到终端。
2. 改用journal实时查看：这其实是systemd推荐的日志管理方式，用下面的命令实时跟踪服务日志：

   journalctl -u scriptA.service -f
   

   它会把journal里属于这个服务的日志实时输出到终端，还支持过滤、搜索等功能，比直接看终端输出更灵活。

为什么你之前配置StandardOutput没成功？ #

大概率是因为你的脚本是forking类型的服务（启动后会后台运行），这时候StandardOutput只能控制父脚本的输出，而后台子进程的输出已经脱离了当前终端的控制，只能被journal捕获。这种场景下，要么改脚本为前台运行，要么用journalctl -f来查看日志。

内容的提问来源于stack exchange，提问作者Gulili