Translate

Image of Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series)
Image of Operating System Concepts
Image of Modern Operating Systems (3rd Edition)
Image of Linux Kernel Development (3rd Edition)

Systemd Snapshots

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.

Comments are closed.