How to reexecute the systemd manager

Reexecuting the systemd manager is a narrow maintenance action for moments when PID 1 itself needs to restart its own process image without a full reboot. It is most useful after a systemd package upgrade or while troubleshooting manager-level behavior that a normal unit reload does not touch.

The systemctl daemon-reexec command tells systemd to serialize its current manager state, exec the manager process again, and restore that state after the new process image starts. That makes it heavier than daemon-reload, which only rereads unit files and generators without replacing the running manager process.

Examples below target the system manager and use sudo. This operation is mainly meant for upgrades and debugging, so it is worth checking the current manager state first and keeping console or out-of-band access available on critical hosts. If unit files were edited, run daemon-reload separately because reexecuting the manager does not reparse changed unit definitions on its own.

Steps to reexecute the systemd manager:

Open a terminal session with an account that can use sudo.
Check the current manager state before the reexecution.
```
$ systemctl is-system-running
running
```
A result such as degraded or maintenance does not block daemon-reexec, but the existing failure should be understood before changing the manager state again.
Run the manager reexecution command.
```
$ sudo systemctl daemon-reexec
```
daemon-reexec reexecutes the running systemd manager after serializing its state. It does not restart every service, and it does not replace a separate sudo systemctl daemon-reload when unit files or drop-ins changed.

Related: How to reload the systemd manager configuration
Confirm that the manager is answering requests again after the handoff.
```
$ systemctl is-system-running
running
```
If this command hangs, returns a bus error, or the SSH session drops, stop retrying and move to a local console or out-of-band session before making more manager changes.
Review the current boot journal for the reexecution messages.
```
$ sudo journalctl -b --no-pager --grep=Reexecut -n 2 -o cat
Reexecuting.
Reexecuting requested from client PID 3706 ('systemctl') (unit init.scope)...
```
The client PID in the journal entry helps confirm which command requested the reexecution when several administrators are working on the same host.

Related: How to view system logs using journalctl
List any remaining manager jobs after the reexecution.
```
$ systemctl list-jobs --no-pager
No jobs running.
```
No jobs running. is the normal idle result. Expected boot or shutdown work may still appear on busy systems, so investigate only unexpected queued jobs before continuing with the maintenance window.