1

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

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 '18 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 '18 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 '18 at 11:34
  • 1
    I suggested the iteration feature to the snapper project here: github.com/openSUSE/snapper/issues/450 – Archibald Nov 18 '18 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.