continue cleanup in case of failure about snapper

[lnussel]

Regarding the reason. The snapshots mentioned above only contained an info.xml but no snapshot subvolume anymore. After remove those directories, snapper-cleanup failed on a few more snapshots that basically only contained garbage in the snapshot directory, eg info.xml.tmp-K2iuHC or filelist-324.txt.

[lnussel]

last but not least cleanup of yet another snapshot failed because it had another subvolume in it. The log contains no hint which snapshot is affected in that case.

[aschnell]

Which snapper version are we talking about here?

[lnussel]

Not sure why I saw your question only now :( Looking at the logs

2024-01-24 01:39:28 MIL libsnapper(23886) Snapper.cc(Snapper):98 - snapper version 0.10.7
2024-01-24 01:39:28 MIL libsnapper(23886) Snapper.cc(Snapper):99 - libsnapper version 7.4.0

[aschnell]

The reason for the failure is not clear to me: The initial log shows "btrfs_util_delete_subvolume_fd() failed, errno:39 (Directory not empty)". AFAIS that happens when the btrfs snapshot itself cannot be deleted. I reproduced that by placing a second snapshot inside a snapshot. But that does not fit your second comment.

In your third comment you write that the number of the snapshot that could not be deleted in not in the logs. It should be included in the log of the systemd service together with the information that the cleanup failed.

Which brings me to the overall problem. Simply ignoring the failure would result in more recent snapshots to be deleted (e.g. due to the space limits). If there are several un-removable snapshots there might not be enough recent snapshots anymore to rollback to a working state. So the user have to check failures of systemd services.