I have a btrfs setup with multiple subvolumes mounted to different places of the file system. Each subvolume has a configuration for snapper:

cat /etc/conf.d/snapper

SNAPPER_CONFIGS="root home [...]"

The service for creating snapshots on boot is defined in the file

cat /usr/lib/systemd/system/snapper-boot.service

ExecStart=/usr/bin/snapper --config root --cleanup-algorithm number --description "boot"
ExecStart=/usr/bin/snapper --config home --cleanup-algorithm number --description "boot"

Instead of adding one line per subvolume, which is error-prone, I'd like to read the list of snapper configurations and iterate.

Is this possible?

Is it advisable?

1 Answer 1


Yes, it's possible to implement that.

A simple way would be to use a shell script that would call snapper repeatedly, once for each config. A for loop would be enough to do that, it seems.

You can even do it inline in the systemd unit file:

ExecStart=/bin/sh -e -c '. /etc/conf.d/snapper; for conf in $$SNAPPER_CONFIGS; do /usr/bin/snapper --config "$$conf" --cleanup-algorithm number --description "boot"; done'

Note that you need to escape the $s, so that systemd doesn't try to interpret those as systemd variables and instead lets the shell interpret them. (In my opinion, using an external shell script that you call in ExecStart= is a cleaner approach, then you don't need to deal with escaping and don't need to cram everything into a single line either.)

Another option would be to modify snapper itself so it could handle that natively. Say, make it read that config file and handle those configs whenever it's called without any --config arguments. That would be an even cleaner approach.

Whether it's advisable or not... I guess it depends. If you're getting this snapper-boot.sevice unit from a package from your distribution, then you might have trouble whenever there's a package upgrade that would touch that file. So, in a way, it depends on your particular situation.

If this unit file is indeed shipped with a package from your Linux distribution, you might want to consider opening a bug report to them, asking them to avoid hardcoding config names in the unit file.

If it's not owned by your distribution, then consider storing it in /etc/systemd/system instead, since the /usr/lib is typically reserved for files shipped and managed by the Linux distribution.

  • 1
    Regarding the ownership of /usr/lib/systemd/system/snapper-boot.service: You said that it was inadvisable to change this file, if it is managed by the package management system. On my Arch system, this is the case (verify by executing "pacman -Ql snapper | grep snapper-boot"). Therefore i'll take your advice to create a new file in /etc/systemd/system.
    – Archibald
    Nov 18, 2018 at 11:05
  • 1
    @Archibald Take a look at command systemctl edit, which is meant to create overrides for the unit files shipped with your distribution.
    – filbranden
    Nov 18, 2018 at 11:27
  • 1
    @Archibald You might want to file a bug report/feature request with Arch Linux too... Since this seems like a config duplication/limitation of their setup, they might want to address it there as well.
    – filbranden
    Nov 18, 2018 at 11:34
  • 1
    I suggested the iteration feature to the snapper project here: github.com/openSUSE/snapper/issues/450
    – Archibald
    Nov 18, 2018 at 12:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .