What is systemd? Originally, back in the 2009 and 2010 days, Lennart Poettering was promoting the idea of systemd as a replacement for the System V (SysV) init subsystem which was then the default Linux init subsystem. Unfortunately like all of Poetterings projects, the goals and complexity of the project shifted over time. Nowadays, according to some reports, Poettering claims that systemd is not an init replacement but is a set of components needed to build up an operating system on top of the Linux kernel.
The general idea is that systemd is the first process started and it then supervises the entire system (hence the name). It is based around the notion of units. Units have a name and a type. Since their configuration is usually loaded directly from the file system, these unit names are actually file names. There are several kinds of systemd units:
- Service: a daemon that can be started, stopped, restarted, reloaded.
- Socket: a socket in the file-system or on the Internet.
- Device: a device in the Linux device tree.
- Mount: a mount point in the file system hierarchy.
- Automount: an automount point in the file system hierarchy.
- Target: used for logical grouping of units.
- Snapshot: the topic of this post
Snapshot units are similar to target units in that they do not actually do anything themselves and their only purpose is to reference other units. Snapshots can be used to save or rollback the state of all services and units of the system.
According to Pottering, systemd snapshots have two intended use cases:
To allow a user to temporarily enter a specific state such as “Emergency Shell”, terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down.
The manpage for snapshots is terse to say the least:
Name systemd.snapshot — Snapshot unit configuration Synopsis snapshot.snapshot Description Snapshot units are not configured via unit configuration files. Nonetheless they are named similar to filenames. A unit whose name ends in ".snapshot" refers to a dynamic snapshot of the systemd runtime state. Snapshots are not configured on disk but created dynamically via systemctl snapshot (see systemctl(8) for details) or an equivalent command. When created, they will automatically get dependencies on the currently activated units. They act as saved runtime state of the systemd manager. Later on, the user may choose to return to the saved state via systemctl isolate. They are useful to roll back to a defined state after temporarily starting/stopping services or similar. See Also systemd(1), systemctl(8), systemd.unit(5), systemd.directives(7)
So how do systemd snapshots actually work?
You create a snapshot using the unfortunately named systemctl command:
# systemctl snapshot fpm1 fpm1.snapshot # systemctl snapshot fpm1 Failed to issue method call: Snapshot fpm1.snapshot exists already. # systemctl snapshot snapshot-1.snapshot #
If you do not provide a name for the snapshot, a name (in this case snapshot-10 is automatically generated.
The new snapshot unit is included in the output of systemctl –all list-units:
# systemctl -all list-units | grep fpm home-fpm.mount loaded active mounted /home/fpm session-1.scope loaded active running Session 1 of user fpm fpm1.snapshot loaded inactive dead fpm1.snapshot
You can view the contents of a snapshot using systemctl show:
# systemctl show fpm1 Id=fpm1.service Names=fpm1.service Description=fpm1.service LoadState=not-found ActiveState=inactive SubState=dead InactiveExitTimestampMonotonic=0 ActiveEnterTimestampMonotonic=0 ActiveExitTimestampMonotonic=0 InactiveEnterTimestampMonotonic=0 CanStart=yes CanStop=yes CanReload=no CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureIsolate=no IgnoreOnIsolate=no IgnoreOnSnapshot=no NeedDaemonReload=no JobTimeoutUSec=0 ConditionTimestampMonotonic=0 ConditionResult=no LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or directory" Transient=no Restart=no NotifyAccess=none RestartUSec=100ms TimeoutStartUSec=1min 30s TimeoutStopUSec=1min 30s WatchdogUSec=0 WatchdogTimestampMonotonic=0 StartLimitInterval=10000000 StartLimitBurst=5 StartLimitAction=none PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=no GuessMainPID=yes MainPID=0 ControlPID=0 Result=success UMask=0022 LimitCPU=18446744073709551615 LimitFSIZE=18446744073709551615 LimitDATA=18446744073709551615 LimitSTACK=18446744073709551615 LimitCORE=18446744073709551615 LimitRSS=18446744073709551615 LimitNOFILE=65536 LimitAS=18446744073709551615 LimitNPROC=125909 LimitMEMLOCK=65536 LimitLOCKS=18446744073709551615 LimitSIGPENDING=125909 LimitMSGQUEUE=819200 LimitNICE=0 LimitRTPRIO=0 LimitRTTIME=18446744073709551615 OOMScoreAdjust=0 Nice=0 IOScheduling=0 CPUSchedulingPolicy=0 CPUSchedulingPriority=0 TimerSlackNSec=50000 CPUSchedulingResetOnFork=no NonBlocking=no StandardInput=null StandardOutput=inherit StandardError=inherit TTYReset=no TTYVHangup=no TTYVTDisallocate=no SyslogPriority=30 SyslogLevelPrefix=yes SecureBits=0 CapabilityBoundingSet=18446744073709551615 MountFlags=0 PrivateTmp=no PrivateNetwork=no SameProcessGroup=no IgnoreSIGPIPE=yes NoNewPrivileges=no KillMode=control-group KillSignal=15 SendSIGKILL=yes SendSIGHUP=no CPUAccounting=no CPUShares=1024 BlockIOAccounting=no BlockIOWeight=1000 MemoryAccounting=no MemoryLimit=18446744073709551615 DevicePolicy=auto ExecMainStartTimestampMonotonic=0 ExecMainExitTimestampMonotonic=0 ExecMainPID=0 ExecMainCode=0 ExecMainStatus=0
You can delete a snapshot using systemctl delete
# systemctl delete fpm1
Interestingly, while the snapshot is no longest listed in the output of systemctl -all list-units, you can still see the contents of the deleted unit using systemctl show. I suspect that this is a bug!
You can revert to a snapshot using systemctl isolate
# systemctl isolate fpm1 Failed to issue method call: Operation refused, unit may not be isolated. # systemctl isolate fpm1.snapshot #
I am not sure where snapshots are stored but a quick review of the source code seems to indicate that they are stored in memory. What is clear is that systemd snapshots do not persist across a reboot.
All in all, I find systemd snapshots to be less than ideal. It is clear that little love or attention has been given to snapshots in systemd; rather they are simply an afterthought. For example, the command line syntax for creating, viewing and deleting systemd snapshots is inconsistent and all over the place.
