systemd notify服务：用SIGHUP异步命令实现同步重载的可行性问询

好问题！你其实已经找对了方向——通过RELOADING=1和READY=1这两个sd_notify信号，完全可以让systemd等待你的服务完成重载，实现systemctl reload的同步阻塞效果。下面详细拆解为什么可行，以及需要注意的关键点：

当你的服务是Type=notify且配置了NotifyAccess=main时，systemd会依赖服务发送的notify信号来判断重载的状态，而不是只看ExecReload命令的退出状态。

具体工作流程 #

当用户执行systemctl reload testd时：

1. systemd执行ExecReload=/bin/kill -HUP $MAINPID——这个命令确实是异步的，会立刻退出，但systemd不会就此认为重载完成。
2. 你的服务收到SIGHUP信号后触发doReload()，首先发送sd_notify(0, "RELOADING=1");（最好加上状态描述，比如RELOADING=1 STATUS="Applying new configuration..."）。
3. systemd收到RELOADING=1后，会进入“等待重载完成”的状态，此时systemctl reload会保持阻塞，不会返回给用户。
4. 当你的服务完成5秒的重载操作后，发送sd_notify(0, "READY=1");，systemd收到这个信号后，才会认定重载成功，systemctl reload命令才会结束并返回。

关键配置与注意事项 #

• 必须确保NotifyAccess=main：这个配置让systemd允许主进程发送notify信号，如果漏掉它，systemd可能收不到你的状态通知，导致systemctl reload立刻返回。
• 超时控制：默认情况下systemd对重载操作的超时时间是90秒，如果你的重载逻辑可能超过这个时长，需要在service单元里添加TimeoutReload=60s（根据实际需求调整），避免systemd误判重载失败。
• 信号可靠性：要保证SIGHUP信号能被服务正确捕获并触发doReload()——比如避免在服务中屏蔽SIGHUP，或者确保信号处理函数不会被阻塞。
• 状态反馈：添加STATUS=字段可以让用户通过systemctl status testd看到重载的实时状态，提升用户体验。

和传统同步ExecReload的区别 #

传统的同步ExecReload是执行一个阻塞式命令（比如直接调用服务的重载脚本），systemd等待该命令退出才认为重载完成。而你的方式是让服务自己掌控重载的生命周期，更适合内部有复杂逻辑的服务（比如需要重新加载配置、重启子进程、连接外部资源等），灵活性更高。

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