Connector logs
A host with the connector installed writes its logs to the systemd journal, and it writes them from more than one unit. The daemon is one of them. Updates, rollbacks and every act on a plugin are logged by the units that perform them, so a question about why something changed on the host is often answered outside the daemon's own journal. This page applies to a host where the one-line installer ran. A Wazuh Cloud environment is not installed that way and has none of these units.
The units that write logs
| Unit | What it is | Read it for |
|---|---|---|
fleet-connector.service | The daemon. Runs as root with Restart=always, started as /usr/local/bin/fleet-connector --config /etc/fleet-connector/connector.yaml. | The session to the gateway, heartbeats, plugin status, downloads it staged, and whether self-update is armed. |
fleet-connector-reconcile.service | The reconciler. A short-lived root process with no network, which installs what the daemon staged and performs the plugin acts. | Why the connector or a plugin was installed, removed, restarted, stopped or rolled back, and why a request was refused. |
fleet-connector-reconcile.path | The trigger that starts the reconciler as soon as a request appears under /var/lib/fleet-connector/upgrade/requests/. | Rarely. It logs only that it fired. |
fleet-connector-reconcile.timer | The safety net that starts the reconciler 3 minutes after boot and every 15 minutes after its last run, for a request the path unit missed. | Rarely, for the same reason. |
fleet-connector-confirm.service | The confirm step, armed by a swap and run 180 seconds after it by fleet-connector-confirm.timer. It judges every swap, of the connector and of a plugin, and puts back what did not confirm. | Whether an update held, and every automatic rollback. |
fleet-plugin@<service>.service | One unit per plugin, running as the fleet-plugin-<service> user with Restart=always, and given 25 seconds to stop. | The plugin's own log. What a plugin writes there is part of that service's documentation, not Fleet's. |
The daemon's journal does not carry an automatic rollback. A new version that
did not confirm is put back by the confirm step and logged in the confirm unit's
journal, and the daemon only reports the outcome to Fleet afterwards. Reading
journalctl -u fleet-connector alone is the most common way to miss why a
version changed.
Three commands worth knowing
journalctl -u fleet-connector -f
journalctl -u fleet-connector-reconcile -u fleet-connector-confirm --since "1 hour ago"
journalctl -u fleet-plugin@vesper -f
The first follows the daemon. The second shows the reconciler and the confirm
step together, in order, which is the full story of an update or a plugin act
from the moment it was installed to the moment it was judged. The third follows
one plugin, and the service name after the @ is the one Fleet shows for it.
sudo fleet-connector status complements the journal with the state on disk:
what runs, what is kept for a rollback, what is staged or pending, and the last
outcome of each component. See the command reference.
What the daemon says when it starts
The lines that close a start name the version, the gateway, and what the host will do with an update:
self-update: armed (<reason>); artifacts accepted only from dl.fleet.wazuh.com
fleet-connector <version> starting; gateway=wss://connect.fleet.wazuh.com
A host that cannot update itself says self-update: off, <reason> instead. A
host whose owner turned updates off says so by naming the file and the key, as
in self-update: DISABLED in /etc/fleet-connector/connector.yaml (upgrade.enabled: false); every directive from the console will be ignored.
See Connector configuration for those keys.
The sentences that mean healthy
The confirm step writes one line per component it judged. These two mean the update held:
core <version> confirmed (previous <version> kept at <path> for --rollback)
plugin <service> <version> confirmed (unit active, <n> restarts since the swap)
A plugin is confirmed when its unit is active and systemd has not had to restart it since the swap, or when the connector has already seen the plugin report the new version itself.
The sentences that mean a rollback
core <version> did not report in within 180 s; restored <version> from <path>
plugin <service> <version> did not stay up within 180 s (unit <state>, <n> restarts); pointed <path> back at <path>
After a rollback the confirm step restarts the unit, and the connector reports
the undone version to Fleet as failed, so that version is not offered to the
host again. A plugin with no previous version to go back to is stopped and
disabled instead, and the line says so. The outcome recorded for a rolled-back
connector reads the new binary did not confirm within 180 s (it opened no session and did not stay up); rolled back to <version>,
and sudo fleet-connector status prints it as the last result.
The reconciler logs a failure of its own before the confirm step runs when a
new plugin version does not come up at all:
reconcile: plugin:<service> <version> did not come up (<why>); <path> points back at <path>.
A rollback by hand
An operator rollback prints its lines on the terminal that ran it and writes
nothing to the journal beyond the unit restart. It restores the previous
version, restarts the unit, and records the undone version as failed with the reason rolled back on the host by an operator,
which sudo fleet-connector status shows afterwards. See
Connector lifecycle for when to use it.