Socket activation versus traditional daemon mode

Systemd socket activation starts the relevant libvirt daemon only when a client connects. Traditional mode keeps the service process running all the time.

How socket activation behaves

With socket activation, the .socket unit owns the listening endpoint and spawns the .service unit on demand.

systemctl status virtqemud.socket virtqemud.service
systemctl status libvirtd.socket libvirtd.service

systemctl status

Use systemctl status on both the .socket and the .service units together. Looking at only the service is how operators misread healthy socket activation as a failure.

Traditional mode

Traditional mode is simpler to reason about during debugging because the service is expected to stay resident. It can still be the right choice for older automation or when you want more obvious steady-state process visibility.

What changes for operators

• systemctl status ...service is not enough by itself.
• Socket ownership matters as much as process ownership.
• Journal timestamps often begin exactly when the first client connects.

Quick decision points

Use socket activation when you want the default modern systemd flow and clean idle behavior.

Use traditional mode only when you have a concrete compatibility reason and you understand which sockets or listeners must be disabled first.

Socket activation pattern

The pattern is consistent: verify the listening socket first, then the service, then the journal entries created when the first client connects.