snapper: update to 0.13.0

[Swiddis]

In addition to the version update, two changes:

• Removed the snapperd service: snapper: update to 0.13.0 #59544 (comment)
• Cleaned some build deps:
  • libboost_thread: part of boost-devel-minimal as of at least 0a420a4
  • e2fsprogs-devel: no longer a snapper dependency as of 0.12.2

Testing the changes

• I tested the changes in this PR: YES, snapshot browsing+creating+rollback

Local build testing

• I built this PR locally for my native architecture, x86_64-LIBC

[Duncaen]

• Snapperd isn't a continuous daemon, it's short-lived and meant to run on a timescale near the backup interval (in the OpenSuse package it's on a 1 hour timer, afaict snapper doesn't support sub-hour backup intervals). The current service has an infinite rerun loop with snapperd, when it has nothing to do it waits 60s and exits. I updated the service to use snooze to run hourly.

Do you have any source for that, a quick look over the upstream systemd services doesn't give this impression.

https://github.com/openSUSE/snapper/blob/0d5e019526b5efaf51dce52cd1d08a9adfd3cf32/data/snapperd.service#L4

There are some .timer units, but none of them specifically start the snapperd service.

https://github.com/openSUSE/snapper/tree/0d5e019526b5efaf51dce52cd1d08a9adfd3cf32/data

[Swiddis]

I got the conclusion by spinning up a clean Tumbleweed VM and watching it, and with some grepping found a timer for snapperd. But information on how it works is sparse, manpage just says "a dbus service." I'm still not sure what the daemon actually does, my understanding is timeline does most of the overall timing management so my best guess is this is some sort of housekeeping job. When I'm next at a computer I'll poke the VM some more and try to find more info, maybe strace it or something?

[Swiddis]

Got home, read more, learned about dbus & dbus services & how to trace dbus services (busctl is nifty).

I guess I misread the timeline timer as the snapperd timer, but when snapper is invoked it automatically starts snapperd in the background, so it looked similar. That daemon is reused by any concurrent snapper processes. It is designed to shut itself off after a 60 second idle timeout, and repeatedly restarting it is a no-op. Snapperd itself seems to primarily be focused on config management (== metasnappers) & just making sure concurrent snapshot operations don't step on each other. It serializes messages and shells out the work to snapper (and the frontend binary is just a client for the dbus service).

So the service coming up at boot is an illusion, it's triggered because osuse does snapshots on boots and the daemon sticks around. The 1h timer is also an illusion because that's just from the ordinary snapshot timeline.

tldr: To my best understanding, the correct approach is don't package a snapperd runit service at all. When users set up their backup policy the tools will automatically spawn it as needed with the packaged dbus service.

[Swiddis]

The dbus service was introduced in version 0.8.14, long after the void package was added, which explains why we have the sv in the first place: https://github.com/openSUSE/snapper/pull/551/changes#diff-d2cb881e7ee649851738af6c0298b8cdd41fad323a266af36294e5ca49dc2827