Sieste – Siesta: Snap Before a Nap

After enjoying a rich Menu du jour with green snapper and vegetables, probably served with some white wine, you may want to get some rest. In France “Sieste”, also known as “Siesta” in Italy and Spain, is a tradition that unfortunately is not common in other countries, such as Germany.

It seems to be common around the world though, to not necessarily login to and logout from your workstation, but just suspend it, while not working on it.

While human beings don’t get their Siesta everywhere, the machines do. Sigh.

Subsequently, the first question, when presenting “pam_snapper” to SUSE colleagues, was: “Do we need this at all?” And this question was raised in Andreas’s Google+ circle as well.

The question about the use case indeed is valid, if we were assuming that this feature is only targeting login into a single person’s desktop. Besides this obvious use case, there are two others at least:

• Remote login into a machine as a developer or administrator, e.g., using SSH and with “UsePAM yes” set in /etc/ssh/sshd_config. People doing so may log in and log out more frequently.
• Using this also for the root user. A company might consider it useful to trigger a snapshot of the system partition, before an administrator starts changing something. Obviously, this is not helpful to prevent “malicious” change attempts, but it can help to create a fallback in case of oversights. Enable this by using pam_snapper’s “rootasroot” option.

Suspend…

Let’s come back to the claim that most single desktop users nowadays suspend or hibernate their systems instead of a login/logout circle. If this is true, why not snapshot just before sending the machine to sleep?

In our internal discussion about this approach, some people raised concerns and caveats, best summarized by one of our Release Managers: “I’m not sure that it’s a good idea to have this during suspend or resume. When the machine is put to sleep/hibernate, the user wants it to happen NOW, not in 1 second or two. And with the least possible risk of having an error happening there. Like, a full filesystem due to a snapshot”.

Fortunately, the risks are not that high, it seems:

• Before suspending, the filesystems should be flushed anyway, thus the additional three blocks it needs to create the snapshot don’t make a significant difference. A quick test reveals:

# time snapper create -p -d "siesta"
116

real    0m0.091s
user    0m0.004s
sys     0m0.008s

• “Disk full” due to a snapshot does not happen when you take the snapshot, but when you start changing data that is snapshotted already. Then Copy-on-Write happens and starts filling your disk. Frankly, if the disk is full already, you have other problems anyways, and a failing btrfs snapshot should be your least concern.
• Finally, you don’t have to enable snapshotting for suspend, do you?

So, what do we need to happen for the computer to have a nap after lunch?

For Linux systems using the pm-utils infrastructure, you can implement additional actions by putting a script of executable to /usr/lib/pm-utils/sleep.d/. Here is my /usr/lib/pm-utils/sleep.d/08_snapper:

#!/bin/bash

. /usr/lib/pm-utils/functions
. /etc/sysconfig/snapper

RETVAL=0
if [ "$SNAPPER_SUSPEND" == "yes" ]; then
  case "$1" in
    hibernate|suspend)
      if [ "$SNAPPER_ALL_SUBVOLS" == "yes" ]; then
        echo "Snapshots for all volumes ..."
        for CCC in $SNAPPER_CONFIGS; do
          if [ -f /etc/snapper/configs/$CCC ]; then
            echo -e -n "$CCC #"
            snapper -c ${CCC} create -p -d "$1"
            RETVAL=$?
          fi
        done
      else
        echo "Snapshots for users logged in only ..."
        for UUU in $( who | cut -d' ' -f 1 | sort -u ); do
          snapper list-configs | grep home_${UUU}
          RETVAL=$?
          if [ "$RETVAL" == "0" ] ; then
            echo -e -n "home_${UUU} #"
            snapper -c home_${UUU} create -p -d "$1"
            RETVAL=$?
          fi
        done
      fi
      ;;
    *)
      ;;
  esac
fi
exit $RETVAL

As discussed, we want to control if snapshotting happens at all. Configuration variables on openSUSE and SUSE Linux Enterprise should be placed into /etc/sysconfig/[tool], and so I reused the already existing /etc/sysconfig/snapper file, and extended it:

## Path: System/Snapper
## Type:        string
## Default:     ""
# List of snapper configurations.
SNAPPER_CONFIGS="root home_mge "

## Type:        yesno
## Default:     yes
#
# Shall snapshots be created during suspend/hibernate
#
SNAPPER_SUSPEND="yes"

## Type:        yesno
## Default:     yes
#
# If snapshots shall be created, then for all subvolumes
# with a snapper configuration or for users which are
# currently logged in only?
#
SNAPPER_ALL_SUBVOLS="yes"

With these two small pieces in place, my notebook on suspend snapshots all subvolumes with a snapper config, as intended.

…Resume

To wake up, take a double espresso macchiato, with sugar at your choice. Drink it hot!

When reading /etc/sysconfig/snapper above, you might have noticed some meta comments such as “Type: yesno”. Curious about those? More soon…