让我逐个给你拆解这两个问题：

答案是不一定，大部分常规场景下它是靠谱的，但存在不少例外情况：

• 当服务进程不按systemd的规则出牌：比如进程启动后手动脱离了systemd的控制组（cgroup），systemd会误以为服务还在运行，但实际进程已经不受它管控甚至已经退出；反过来，要是有外部进程偷偷加入了服务的cgroup，systemd也可能误判状态。
• oneshot类型服务的特殊情况：这类服务执行完任务就会退出，systemctl status会显示exited状态——这其实是准确的，但如果用户预期服务要一直后台运行，就容易产生误解。
• 第三方工具直接操作进程：比如你用kill命令直接干掉服务的主进程，而不是通过systemctl stop，systemd需要一点时间来同步进程状态，短时间内status显示的还是之前的“running”，直到它的监控机制检测到进程消失。
• 业务层面故障但进程存活：比如Web服务的主进程还在，但端口已经不监听、完全无法处理请求，systemctl status只会告诉你进程在运行，没法感知业务逻辑层面的“挂掉”。

这个得看你的app.service配置细节，核心是systemd靠cgroup和进程监控跟踪状态，只要操作绕开了systemd，就可能出现状态不一致：

• 如果app.service的ExecStart是调用appctl start，且Type配置（比如Type=forking或Type=simple）和appctl的启动逻辑匹配：
  • 当appctl restart停止原进程时，systemd会检测到监控的进程退出，此时systemctl status会先显示failed或exited（具体看服务的Restart配置）；如果appctl restart成功启动了新进程，且新进程留在了systemd的cgroup里，systemd会重新识别到进程，状态变回running。但如果新进程脱离了cgroup，systemd会认为服务已停止，可实际应用还在跑，就出现了状态偏差。
• 如果app.service是直接启动应用的主进程，而非通过appctl：
  • appctl restart相当于绕过systemd直接杀进程再启动，systemd会检测到原主进程退出，此时如果服务配置了Restart=always这类规则，它会自动重启服务，status最终显示running；如果没配置自动重启，status会显示failed。但如果appctl restart启动的新进程不在systemd的cgroup里，systemd会认为服务没运行，可实际进程是活的。
• 最坏的情况：如果appctl restart只停了进程没启动成功，那systemctl status会明确显示服务failed或exited。

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