I'm working on setting up a Linux server that will have dozens of daemons controlled by systemd. The daemons are grouped into targets so that they can be brought up and down in groups, but the system administrators can manually control individual services. I am looking for a way to preserve the state (which services are activated) through a reboot. The idea is that people debugging, testing, and developing on the server can reboot it if needed and have the system come up in the same configuration as it was before the reboot.

systemd's snapshot functionality seems ideal for this, but as far as I can tell you can't write a snapshot to disk for use later.

My initial plan was to create a symlink from multi-user.target.wants/ to a service called bootingup.service. Every target the system administrator activates would then rewrite bootingup.service.d/bootingup.conf to launch the target that was just activated. This would mean that on boot the system would activate the most recently launched target, but it wouldn't remember any services that were individually activated/deactivated.

Is there a way to make systemd remember the state of all services across a reboot?

  • 1
    That's what enable and disable are for. systemd keeps track of all services enabled by symlinks from /usr/lib/systemd/system/ to /etc/systemd/system/[target]. enabled means the service starts at boot, disabled means it doesn't. Services can be started/stopped regardless of whether or not they are enabled/disabled. – Centimane Apr 17 '17 at 10:43
  • Yes, but that doesn't fully answer my question. Suppose that a target is activated by the user and then later the system is shut down. Systemd doesn't "remember" that the target is supposed to be active on the next boot. Initially I thought that I could get around this by making the user always use sudo systemctl enable --now TARGET.target. The problem is that if TARGET.target is deactivated through a Conflict= tag in another unit it is not disabled. – Dennis Dragonbain Apr 20 '17 at 17:02
  • Sounds like you want to alias systemctl start to a script that will handle the disabling/enabling that you want. systemd does not preserve start/stop commands, only enable/disable commands. Systemd only respects the symlinks in the default target and all of their dependencies. – Centimane Apr 20 '17 at 17:10
  • I'd also like to add the note that if your admins are developing services on this server it's best if they know what they're using rather than relying on the "current state". When developing the service, they should know what the dependencies are, and configure them as such. If a service is needed for the server's function it should be enabled. This seems like a crutch for people to not know what they've done. – Centimane Apr 20 '17 at 17:18

I'm going to start this answer off with:

I recommend you force the developers to use things like enable, disable, after and wants in the systemd services properly rather than doing a dump and restore of what's running.

Now that I've got that out of my system...

systemctl snapshot can help you do what you're looking for.

When running systemctl snapshot ${SNAPSHOT_NAME} systemd creates a unit called ${SNAPSHOT_NAME}.snapshot. This unit seems to only exist in memory. However, you can still query it using systemctl.

Using systemctl show ${SNAPSHOT_NAME}.snapshot will list all the information systemd collected for the snapshot, of particular note to you would be the Wants= / After= sections (which both seem to be the same) which lists all the units that were active at the time of the snapshot. If you were to parse that list and throw it into a custom target you could achieve what you're looking for using systemctl isolate ${CUSTOM_TARGET}.

systemctl isolate

Start the unit specified on the command line and its dependencies and stop all others. If a unit name with no extension is given, an extension of ".target" will be assumed.

This is similar to changing the runlevel in a traditional init system. The isolate command will immediately stop processes that are not enabled in the new unit, possibly including the graphical environment or terminal you are currently using.

Note that this is allowed only on units where AllowIsolate= is enabled. See systemd.unit(5) for details.

You could even write a service that updates the ${CUSTOM_TARGET} Wants / After sections on shutdown.


I think that you should to use some configuration manager like Puppet or Ansible to do this, configurations manager is the best way to keep your system the way you want it . Systemd snapshots do not persist across a reboot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.