[GH-ISSUE #12] Make monitor script a daemon #285

New issue

Closed

opened 2026-03-01 17:25:05 +03:00 by kerem · 3 comments

kerem commented

2026-03-01 17:25:05 +03:00

Owner

Originally created by @abh on GitHub (Jun 3, 2011).
Original GitHub issue: https://github.com/abh/ntppool/issues/12

Change monitor script to run continuously (under supervise, systemd, launchd etc – not daemonized, though that could be an option, too).

Whenever the last API 'poll' returned servers to check it should do so again immediately after posting results; if there were no servers to check, wait two minutes before polling again.

Originally created by @abh on GitHub (Jun 3, 2011). Original GitHub issue: https://github.com/abh/ntppool/issues/12 Change monitor script to run continuously (under supervise, systemd, launchd etc – not daemonized, though that could be an option, too). Whenever the last API 'poll' returned servers to check it should do so again immediately after posting results; if there were no servers to check, wait two minutes before polling again.

kerem

2026-03-01 17:25:05 +03:00

closed this issue
added the
monitor
label

kerem commented

2026-03-01 17:25:06 +03:00

Author

Owner

@loewis commented on GitHub (Jun 4, 2011):

I propose https://github.com/loewis/ntppool/tree/issue12 as a patch. This creates a systemd "simple" service, which terminates on SIGTERM. I left in all the dies, which I hope should show up in the log files somehow. In some of the cases, it is probably better just to log an error message, and continue with the next loop iteration. If it dies, it should be the responsibility of the process manager to restart it (taking into consideration restart frequencies and such).

@loewis commented on GitHub (Jun 4, 2011): I propose https://github.com/loewis/ntppool/tree/issue12 as a patch. This creates a systemd "simple" service, which terminates on SIGTERM. I left in all the dies, which I hope should show up in the log files somehow. In some of the cases, it is probably better just to log an error message, and continue with the next loop iteration. If it dies, it should be the responsibility of the process manager to restart it (taking into consideration restart frequencies and such).

kerem commented

2026-03-01 17:25:06 +03:00

Author

Owner

@abh commented on GitHub (Jun 4, 2011):

Didn't test it, but at a glance it looks good. Thanks! I pulled it into my master branch and will try it later.

@abh commented on GitHub (Jun 4, 2011): Didn't test it, but at a glance it looks good. Thanks! I pulled it into my master branch and will try it later.

kerem commented

2026-03-01 17:25:06 +03:00

Author

Owner

@abh commented on GitHub (Jun 6, 2011):

commit 4e876252d7
Author: Martin v. Loewis martin@v.loewis.de
Date: Sat Jun 4 22:38:49 2011 +0800

Change monitor script to loop until SIGTERM is received,
or an error occurs.

@abh commented on GitHub (Jun 6, 2011): commit 4e876252d7616c447437fa7c121fcc6621acd4fe Author: Martin v. Loewis martin@v.loewis.de Date: Sat Jun 4 22:38:49 2011 +0800 ``` Change monitor script to loop until SIGTERM is received, or an error occurs. ```