Automatic snapshots create two 'boot' snapshots within a single session if the time hits x-o'clock in less than 10 minutes after powering on the PC

[NintendoManiac64]

Describe the bug
When using automatic snapshots, if you power on the PC at something like 10:55 then, when the time hits 11:00, a 'boot' snapshot will be created... and then, without suspending, rebooting, or shutting down your PC, once a few minutes pass and the system uptime reaches 10 minutes, a second 'boot' snapshot will be created.

To Reproduce
Steps to reproduce the behavior:

1. Have Timeshift configured to make automatic boot snapshots
2. Turn off your PC
3. Five minutes before the hour, turn on your PC (e.g. turn it on at 10:55; you can also just set your BIOS or UEFI to such a time and just make sure to be disconnected from the internet)
4. Observe that, when the clock hits 11:00, a Timeshift snapshot will be created
5. Without suspending, rebooting, or shutting down, wait a few more minutes until, somewhere around 11:04 to 11:06 when system uptime reaches 10 minutes
6. Observe that another automatic snapshot will be created
7. Open up Timeshift and observe that the two snapshots taken in steps 4 and 8 are both tagged as 'boot' snapshots

Expected behavior
There should only be a single 'boot' snapshot created during a given single session, ideally being created around 10 minutes after boot to avoid the wackiness that occurs when an automatic snapshot tries to be created during the boot-up process resulting in weird temporary graphical glitches that makes you think that you broke something (at least on my Thinkpad T420 with an i5-5250M + integrated graphics and a 128GB Samsung 830 SSD).

Possibly related to issue #124

It may be worth mentioning that, in theory, both this issue and #124 could be solved by just having the on-the-hour cron job for Timeshift be delayed by 10 minutes (that way it would never be able to run before the normal 10-minutes-after-boot cron job and would not only create just a single 'boot' snapshot but also avoid the issue of snapshots possibly being created during boot-up)

UPDATE: I suppose an alternative would be to just never create two "boot" snapshots within a single session, though that can still result in the "boot" snapshot being taken like a single second after logging in depending on the time.

Screenshots

System:

• Mint 21.1 (upgraded from Mint 21.0)
• Cinnamon
• Timeshift v22.11.2

[AndersHeileHass]

For some reason I didn't notice the issue was related to booting within 10 minutes of a new clock hour.

I think the maintenance task that runs hourly is triggered by the new clock hour and not hourly after boot: https://linuxmint-installation-guide.readthedocs.io/en/latest/timeshift.html https://linuxmint-installation-guide.readthedocs.io/en/latest/_images/timeshift-3.png
I think maintenance task basically runs the timeshift --check command thereby makes a boot snapshot within 10 minutes after boot, just like running the command yourself within 10 minutes after boot.

I don't know if maintenance task can be delayed by the 10 minutes after boot as well. So it won't trigger a boot snapshot before the scheduled boot snapshot 10 minutes after boot.
At least the simplest solution I can see without making other issues nor requiring more complicated changes (which could be nice to have anyway but I can understand time is limited and it might make more issues which takes even more time to fix).

[NintendoManiac64]

I suppose an alternative would be to just never create two "boot" snapshots within a single session, though that can still result in the "boot" snapshot being taken like a single second after logging in depending on the time.

[AndersHeileHass]

I have found out that Timeshift makes timeshift-boot and timeshift-hourly in /etc/cron.d

• timeshift-hourly runs timeshift --check --scripted every clock hour (0 * * * * root timeshift --check --scripted).
• timeshift-boot runs timeshift --create --scripted --tags B 10 minutes after boot (@reboot root sleep 10m && timeshift --create --scripted --tags B).

I would assume the point of waiting 10 minutes is there can be issues with making a snapshot too close to boot. But right now if you boot just before new clock hour, you will make a snapshot immediately. I dunno if you can write @reboot root sleep 10m && 0 * * * * root timeshift --check --scripted or something to that effect.

[DJCrashdummy]

i guess the best solution would be for all timed snapshots to skip if there is already a snapshot pending because of a (re)boot... as it also makes no sense to have 2 snapshots within this short timespan (which seems to be <=10 minutes (hardcoded)).
but the more important and first part of the solution is mentioned at #124 (comment): that the timed snapshots shouldn't be able to take place closer to a (re)boot as the @reboot-snapshot itself, no matter if it is active or not.

yes, i'm aware this would also result in no snapshot ever being created if the machine always runs for <10 minutes, no matter what - or even if all - schedules are activated. ...on the other hand, i guess most users won't change much if the machine only runs always just for that short amount of time. 🤷

[ygerlach]

we could store the boot_id (/proc/sys/kernel/random/boot_id) for each snapshot and check that before creating a new one. I already implemented reading the boot_id for pausing snapshots here #498

[DJCrashdummy]

theoretically that should work similar, because it doesn't make a difference if snapshots are paused manually or because of a boot (for the next N minutes). - but that alone would rather be more or less the solution for #124.

as i'm not sure how Timeshift figures out if more than one snapshot is pending and combines them (which should resp. must also be done in this case to not mess up the rotation), it must be ensured that not 2 "different" snapshots actually take place at the same time after the "(re)boot pause". ...else this feature would only increase the chances that this will happen.

and practically speaking: i'm not 100% sure if this will really work reliable, because if the machine is right at the process of booting while a snapshot should happen, Timeshift may not be paused yet (because of the (re)boot) and hence the snapshot still take place right after resp. during the (re)boot. 😑 🤷

[ygerlach]

timeshift checks if another timeshift process is running before doing anything. So two timeshifts running at the same time is not possible. Thats why timeshift does not create snapshots while it is open.

So just putting the boot_id into each info.json and checking that before creating another boot snapshot should be enough.

I am not saying that we use the "pause feature" to solve this. I am saying we can use some part of the pause feature to solve this. And that part is to fetch and store the boot_id.

[xaos522]

Here is what happens when you boot your system within 10 minutes before the hour

1. at boot time cron starts a 'boot' snapshot, but that process sleeps for 10 minutes
2. the 'hourly' snapshot runs first (presuming hourly snapshots are configured)
3. timeshift detects that no 'B' snapshot exists since booting the system and tags the hourly snapshot with both 'H' and 'B'
4. 10 minutes after the boot the 'boot' snapshot wakes up and creates a new snapshot that is tagged with 'B'
5. You end up with 2 snapshots created within a 10 minutes time span.

For a btrfs setup, this does not 'cost' you much, not in time nor in disk space.

For an rsync setup the cost is greater. Only the deltas take up space, but setting up the 'link farm' takes space and time.
Note that, if your rsync snapshot takes longer that 10 minutes, the second snapshot will fail because the first snapshot still holds the 'timeshift lock'.

In my opinion, only an rsync setup justifies program changes to avoid double snapshots.