How to check GlusterFS geo-replication logs

GlusterFS geo-replication log checks are most useful when a session reports Faulty, a worker stops advancing, or a secondary volume no longer reflects recent writes. The log path returned by the geo-replication configuration points at the gsyncd process that owns the session, so it avoids guessing from directory names while the cluster is already in an incident state.

Geo-replication runs from a primary volume to a secondary target over SSH. GlusterFS keeps primary and secondary geo-replication logs on their respective nodes, while status output shows which brick or worker is stuck before the log file is opened.

Check logs on the node that owns the failing worker, then compare primary and secondary timestamps for the same changelog or error. Log entries can contain hostnames, usernames, volume paths, and file paths, so copy only the lines required for the case and redact identifiers before sharing them.

1. Identify the affected geo-replication session from the primary cluster status.

   $ sudo gluster volume geo-replication gvol-primary \
     geoaccount@snode1.example.com::gvol-secondary \
     status detail
   PRIMARY NODE  PRIMARY BRICK  STATUS  LAST_SYNCED          FAILURES
   pnode1        /bricks/b1     Faulty  2026-06-16 10:04:02  2
   ##### snipped #####

   Use the row with Faulty status, a stale LAST_SYNCED value, or a nonzero FAILURES count to choose the primary node and brick to investigate.
   Related: How to check GlusterFS geo-replication status

2. Print the configured primary log file path for the session.

   $ sudo gluster volume geo-replication gvol-primary \
     geoaccount@snode1.example.com::gvol-secondary \
     config log-file
   /var/log/glusterfs/geo-replication/gvol-primary/gsyncd.log

   Run this from a primary node in the trusted pool. The returned path is safer than assuming a filename from the volume name.

3. Read the primary gsyncd log at the returned path.

   $ sudo cat \
     /var/log/glusterfs/geo-replication/gvol-primary/gsyncd.log
   [2026-06-16 10:07:14.219] I [gsyncd] Worker spawned
   [2026-06-16 10:07:15.004] I [changelog] Processing CHANGELOG.1781590034
   [2026-06-16 10:07:15.662] E [ssh] Host key verification failed for snode1
   [2026-06-16 10:07:15.668] E [repce] secondary exited with status 255
   ##### snipped #####

   Use less for interactive review when the log is large. Keep copied excerpts limited to the timestamp range that explains the worker state.

4. Search the primary log for the error string reported by the incident.

   $ sudo grep -n "Host key verification failed" \
     /var/log/glusterfs/geo-replication/gvol-primary/gsyncd.log
   3:[2026-06-16 10:07:15.662] E [ssh] Host key verification failed for snode1

   Replace the quoted string with the exact symptom, error phrase, changelog ID, or remote host from the case.
   Related: How to enable verbose SSH server logging
   Tool: SSH Key Fingerprint Checker

5. Print the session owner when the secondary log name is not obvious.

   $ sudo gluster volume geo-replication gvol-primary \
     geoaccount@snode1.example.com::gvol-secondary \
     config session-owner
   5f6e5200-756f-11e0-a1f0-0800200c9a66

   The session owner helps match secondary-side log names on systems that do not store them directly under the secondary volume name.

6. List secondary geo-replication log directories on the secondary node.

   $ sudo ls -1 /var/log/glusterfs/geo-replication-secondary
   gvol-secondary

   GlusterFS stores secondary-side geo-replication logs in this directory on secondary nodes.

7. Read the matching secondary gsyncd log.

   $ sudo cat \
     /var/log/glusterfs/geo-replication-secondary/gvol-secondary/gsyncd.log
   [2026-06-16 10:07:13.902] I [repce] connection received from pnode1
   [2026-06-16 10:07:14.248] I [sync] applying changelog CHANGELOG.1781590034
   [2026-06-16 10:07:15.701] W [repce] primary connection closed before acknowledgement
   ##### snipped #####

   Match timestamps, changelog IDs, and remote node names against the primary log before deciding whether the failure is on transport, changelog processing, or secondary apply.

8. Check the glusterd log when the session log is missing or idle.

   $ sudo grep -n "geo-replication" /var/log/glusterfs/glusterd.log
   1:[2026-06-16 10:07:12.911] I [geo-replication] starting gsyncd
   2:[2026-06-16 10:07:15.690] E [geo-replication] gsyncd exited with status 255

   Use glusterd.log to confirm whether glusterd attempted to launch gsyncd when the per-session log path has no new entries.
   Related: How to check GlusterFS logs
   Related: How to manage the GlusterFS service with systemctl

9. Record only the evidence needed for the next action.

   Geo-replication logs can expose cluster hostnames, user names, paths, volume names, and file names. Redact those values before placing excerpts in tickets, chat, or vendor cases.