Feature description
Minor thing, but I thought I'd mention it:
We rely on the words "fail" and "error" in logs to refer to things that are broken that we need to fix, rather than expected failures of low level actions that the system expects to happen and is designed to recover from.
Log the latter type of failure as an informational message (at most).
For specific example of the general problem, on startup, we see this log message:
Aug 09 07:45:10 hostname syncthing[1344]: Failed to fetch latest release information (error="Get \"https://upgrades.syncthing.net/meta.json\": dial tcp: lookup upgrades.syncthing.net on 127.0.0.53:53: server misbehaving" log.pkg=upgrade)
We expect it to be logged as an informational message (suggested wording):
Aug 09 07:45:10 hostname syncthing[1344]: Unable to fetch latest release information, will retry later (message="Get \"https://upgrades.syncthing.net/meta.json\": dial tcp: lookup upgrades.syncthing.net on 127.0.0.53:53: cannot resolve host name" log.pkg=upgrade)
Of course, if you decide that the startup contract for syncthing is to have working DNS available as a system requirement, then the above failure is indeed an error, in which case definitely have the distributed systemd unit file depend on, and start after, nss-lookup.target.
Problem or use case
The ability to use "fail" and "error" as keywords in the log to identify only problems that require remediation, not informational messages.
Alternatives or workarounds
In our case, addressing this particular example, we do override using /etc/systemd/system/[email protected]/override.conf:
[Unit]
Wants=nss-lookup.target
After=nss-lookup.target
Feature description
Minor thing, but I thought I'd mention it:
We rely on the words "fail" and "error" in logs to refer to things that are broken that we need to fix, rather than expected failures of low level actions that the system expects to happen and is designed to recover from.
Log the latter type of failure as an informational message (at most).
For specific example of the general problem, on startup, we see this log message:
We expect it to be logged as an informational message (suggested wording):
Of course, if you decide that the startup contract for syncthing is to have working DNS available as a system requirement, then the above failure is indeed an error, in which case definitely have the distributed systemd unit file depend on, and start after, nss-lookup.target.
Problem or use case
The ability to use "fail" and "error" as keywords in the log to identify only problems that require remediation, not informational messages.
Alternatives or workarounds
In our case, addressing this particular example, we do override using /etc/systemd/system/[email protected]/override.conf: