Certspotter dies when unable to fetch loglist on startup

[robryk]

Currently, when I start certspotter while I have no working Internet connection, it prints an error and exits (the quote below is from systemd's journal):

Dec 05 22:39:05 howl systemd[1]: Started Cert Spotter - Certificate Transparency Monitor.
Dec 05 22:39:05 howl certspotter-start[3167]: /nix/store/707i4p53mw60p5f62krsm83y3p2bphx4-certspotter-0.17.0/bin/certspotter: error loading log list: Get "https://loglist.certspotter.org/monitor.json": dial tcp: lookup loglist.certspotter.org: no such host
Dec 05 22:39:05 howl systemd[1]: certspotter.service: Main process exited, code=exited, status=1/FAILURE
Dec 05 22:39:05 howl systemd[1]: certspotter.service: Failed with result 'exit-code'.
Dec 06 01:55:27 howl systemd[1]: Started Cert Spotter - Certificate Transparency Monitor.

I would rather expect certspotter to continue running even if can't update the loglist:

• if it can't update the loglist but can reach logs, it's clearly desirable to continue following logs,
• even if it can't reach any log, it's considered better to start even without network and start operating when network arrives.

[AGWA]

I recommend modifying your systemd service file to depend on network-online.target as done by the Debian package.

if it can't update the loglist but can reach logs, it's clearly desirable to continue following logs,

certspotter already does this, but the log list is not persisted between runs of certspotter, so if certspotter can't fetch logs when starting up, there are no logs for it to monitor.

even if it can't reach any log, it's considered better to start even without network and start operating when network arrives.

The systemd documentation is just one opinion on this matter and isn't authoritative. It makes sense for mobile devices, but on server systems (which is the only type of system certspotter is trying to support), the benefits are less clear, and have to be weighed against the tradeoffs. In particular, it makes it harder to detect configuration errors, such as a typo in the log list URL. Currently, that mistake is obvious because certspotter exits immediately. If certspotter started up instead, the mistake would go unnoticed until certspotter's next health check, which seems less user-friendly.

[robryk]

 but the log list is not persisted between runs of certspotter

Ah, thanks, that wasn't obvious for me.

Making it dependent on network-online.target still leaves the possibility of a failure to fetch for random reasons (or e.g. because at boot time the local dhcp server was operational, but the default route didn't work), so it's not robust (in the meaning of assuring operation without manual actions) without something like Restart=on-failure too.