SUSE Conversations


Sieste – Siesta: Snap Before a Nap

mge1512

By: mge1512

June 14, 2013 9:23 am

Reads:719

Comments:0

Rating:5.0

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…

VN:D [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)
Sieste - Siesta: Snap Before a Nap, 5.0 out of 5 based on 3 ratings

Tags: , , , ,
Categories: Desktop, Enterprise Linux, openSUSE, SUSE Linux Enterprise, SUSE Linux Enterprise Desktop, SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

Comments are closed.

RSS