SIGNALS
Runtime signals
Signals accepted by the daemon and their operational effect.
section 06 / 14
manual group: virtualization support
living notes: enabled
deep links: enabled
Reference core
verify upstream ↗SIGHUP requests that libvirtd reload its configuration.
Living manual · why this matters
What does SIGHUP mean operationally?
SIGHUP requests a configuration reload. A reload is not the same as restarting every managed guest or rebuilding the virtualization stack. Treat it as a daemon-control operation and verify which configuration changes are reloadable before assuming a signal applied the desired state.
Operator checks
$ systemctl reload libvirtd$ systemctl kill -s HUP libvirtd$ journalctl -u libvirtd -n 100$ virsh list --allWhat to notice
- Use the service manager when possible so the action is auditable and targets the intended unit.
- A daemon reload does not replace validation of guest, network or storage state.
- Modular daemons have their own processes and service units.
Deep reference
Keep going without losing the layer.
Daemonslibvirtd command-line optionsThese are the libvirtd command line switches operators still run into on classic deployments, compatibility wrappers, and older automation. Listen mode Use listen only when the host is intentionally exposing traditional DaemonsSocket activation versus traditional daemon modeSystemd 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 .socketDaemonsvirtqemud and virtproxyd rolesvirtqemud manages QEMU/KVM guests. virtproxyd exists mostly so older clients and URI expectations still work even after the daemon split. virtqemud: where guest work happens Use virtqemud logs when a failure touches domaTroubleshootingGuest start failure: evidence-first triagePreserve the first error. Repeated start attempts can rotate logs, alter locks, and bury the original denial beneath secondary failures. Capture the failed transaction Check dependencies in order Classify the failure befTroubleshootingTroubleshooting playbookUse the same order every time: confirm the URI, confirm the socket, identify the owning daemon, then inspect XML or policy. First response Permissions and polkit If root works and an unprivileged operator fails, check loReferenceFiles, sockets, and service unitsThis page is the quick lookup table for the names operators tend to forget during an incident. Common systemd units | Unit | Purpose | | | | | libvirtd.service | Historical compatibility daemon | | libvirtd.socket | Comp