How to manage the GlusterFS service with systemctl

Restarting or disabling the GlusterFS management daemon changes whether a storage node can coordinate peers, brick processes, and volume operations. Check the service state before maintenance so a planned restart does not get confused with a failed node or a stopped volume.

On systemd hosts, the packaged daemon is managed as glusterd.service. systemctl controls whether glusterd is active in the current boot, whether it starts after reboot, and what systemd recorded when the daemon failed to start or exited unexpectedly.

Service control affects the node, while gluster volume start and gluster volume stop affect named volumes across the trusted pool. Stop or restart glusterd during a maintenance window when possible, and verify peer connectivity before treating the node as ready for normal volume work.

Steps to manage the GlusterFS service with systemctl:

Open a terminal on the GlusterFS server with sudo privileges.
Confirm that the host is booted with systemd.
```
$ ps -p 1 -o comm=
systemd
```
Minimal containers often include unit files but cannot start services with systemctl because systemd is not process 1.

Confirm the glusterd service unit name.

$ systemctl list-unit-files --type=service glusterd.service --no-pager
UNIT FILE        STATE   PRESET
glusterd.service enabled enabled

1 unit files listed.

Check the current glusterd service state.

$ sudo systemctl status glusterd.service --no-pager
* glusterd.service - GlusterFS, a clustered file-system server
     Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-06-16 09:42:18 UTC; 2min 14s ago
   Main PID: 1482 (glusterd)
      Tasks: 9 (limit: 9445)
##### snipped #####

The Loaded line shows the unit file and boot enablement. The Active line shows whether the daemon is running now.

Start glusterd for the current boot when it is stopped.
```
$ sudo systemctl start glusterd.service
```
Confirm that glusterd entered the active state.
```
$ systemctl is-active glusterd.service
active
```
active means systemd is tracking the daemon as running. It does not prove every volume brick is online.

Enable glusterd for future boots and start it now.

$ sudo systemctl enable --now glusterd.service
Created symlink /etc/systemd/system/multi-user.target.wants/glusterd.service -> /usr/lib/systemd/system/glusterd.service.

Use --now when the daemon should be running immediately as well as enabled for reboot.

Confirm that glusterd is enabled for boot.

$ systemctl is-enabled glusterd.service
enabled

Restart glusterd when a full daemon restart is scheduled.
```
$ sudo systemctl restart glusterd.service
```
A restart can interrupt peer management and volume operations on the node. Check active heal, rebalance, and maintenance work before restarting a production storage server.
Stop glusterd only when the node should stop participating in management operations.
```
$ sudo systemctl stop glusterd.service
```
Stopping glusterd can make GlusterFS CLI operations fail from that node and can disrupt brick supervision until the daemon starts again.
Disable glusterd when the node must stay offline after reboot.
```
$ sudo systemctl disable --now glusterd.service
Removed /etc/systemd/system/multi-user.target.wants/glusterd.service.
```
Do not disable the service on an active storage node unless the node is intentionally removed from service or under maintenance.

Inspect recent glusterd journal entries if the service does not become active.

$ sudo journalctl --unit=glusterd.service --boot --no-pager --lines=50
Jun 16 09:42:18 node1 systemd[1]: Starting glusterd.service - GlusterFS, a clustered file-system server...
Jun 16 09:42:18 node1 systemd[1]: Started glusterd.service - GlusterFS, a clustered file-system server.
##### snipped #####

Use the node-local GlusterFS logs when the journal points to a brick, peer, heal, or rebalance symptom.
Related: How to check GlusterFS logs

Confirm peer connectivity after starting or restarting the service.
```
$ sudo gluster peer status
Number of Peers: 1

Hostname: node2
Uuid: 6770f88c-9ec5-4cf8-b9f5-658fa17b6bdc
State: Peer in Cluster (Connected)
```
A standalone test node normally reports Number of Peers: 0. In a trusted pool, every peer should return Connected before volume maintenance continues.
Related: How to check GlusterFS volume status