.NET Core程序作为Linux守护进程运行后无法生成日志文件

我来帮你排查这个问题，主要有几个常见原因会导致log.txt没出现在你预期的目录里：

1. 工作目录不匹配（最可能的原因） #

当systemd运行你的服务时，默认的工作目录是根目录/，而不是你的DLL所在的/home/my username/Desktop/publish目录。你的代码里用的是相对路径"log.txt"，所以文件实际上被写到了/log.txt（根目录下），而不是你以为的publish目录里。

解决办法：在[Service]段添加WorkingDirectory配置，明确指定程序的工作目录：

[Service]
ExecStart = /usr/bin/dotnet "/home/my username/Desktop/publish/SimpleApp.dll"
WorkingDirectory = /home/my username/Desktop/publish
Restart = on-failure

2. 路径中的空格未正确处理 #

你的应用路径/home/my username/Desktop/publish包含空格，直接写在ExecStart里会被systemd解析成两个独立参数（my和username），这可能导致dotnet找不到你的DLL文件——哪怕服务状态显示"已运行"，实际可能是启动失败后被自动重启了。

解决办法：把带空格的路径用双引号括起来，或者用反斜杠转义空格：

# 方法1：用双引号包裹路径
ExecStart = /usr/bin/dotnet "/home/my username/Desktop/publish/SimpleApp.dll"
# 方法2：反斜杠转义空格
ExecStart = /usr/bin/dotnet /home/my\ username/Desktop/publish/SimpleApp.dll

3. 文件写入权限问题 #

如果上面两个问题都解决了还是没生成文件，那就要考虑权限问题：

• 如果systemd默认用root用户运行服务，/home/my username/Desktop/publish目录可能不允许root用户写入；
• 如果你后续指定了非root用户运行，该用户可能没有这个目录的写入权限。

排查与解决：

1. 先查看服务的运行日志，确认有没有权限相关错误：

journalctl -u console.service

2. 如果确实是权限问题，在[Service]段添加User配置，指定拥有该目录写入权限的用户：

[Service]
User = your_username  # 替换成你的实际用户名
ExecStart = /usr/bin/dotnet "/home/my username/Desktop/publish/SimpleApp.dll"
WorkingDirectory = /home/my username/Desktop/publish
Restart = on-failure

最后，更新服务并验证 #

修改完console.service文件后，需要重新加载systemd配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart console.service

之后再检查/home/my username/Desktop/publish目录，应该就能看到生成的log.txt文件了。

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