Timeshift not completing a new snapshot

[johncparr]

Describe the bug
I am experiencing what sounds like the same problem as #590. Both automated and manually initiated snapshots do not complete and remain stuck at high cpu load. The snapshot appears to have been created by looking in /timeshift/snapshots/ but does not appear in the gui. top shows two rsync tasks running at high cpu.

To Reproduce
Steps to reproduce the behaviour:

1. Run a snapshot manually
2. Snapshot progresses as normal and counts down to 00.00.00. Progress stops incrementing close to the end of the bar. Two rsync processes continue at high cpu indefinitely.
3. No Error message

Expected behavior
The creation of a snapshot that is recognised in the gui

System:

• OS - Arch linux fully updated as at 23/04/2020.
• KDE desktop
• Timeshift version 20.03
• Error arose after a system upgrade (sudo pacman -Syu) ~22 April 2020
• Rolling back to an earlier snapshot fixed the issue until upgrade was repeated

2020-04-23_17-00-01_backup.log

Update
I have done some further testing of this problem having rolled back to a working snapshot. On the basis that a recent update has caused this problem I checked the version numbers for the timeshift dependencies listed on the AUR. Three were not at the latest versions. I updated each one individually and checked that timeshift still worked as expected after each update. No issues were found. Finally I did a fully system update which unfortunately recreated the problem.

Update April 30th
I now have a few solutions to this issue thanks to the discussion on several boards. The issue seems to be linked to significant changes in the dhcpcd package when it recently updated to version 9.x. This version mounts filesystems under /var/lib/dhcpcd which results in a huge volume of data, perhaps an infinite amount, to backup.

There are a two solutions I've found that work:

 1. Stop the dhcpcd service while backing up. (not ideal)
 2. Switch the management of network services to NetworkManager. (Haven't found a downside to this yet)

Others report success with a 3rd solution which I haven't tried:

 3, Set the exclude parameters to exclude any folder below /var/lib/dhcpcd

I suppose the question is "can timeshift detect this kind of scenario in the future and work around it behind the scenes?". I'd guess it could be too difficult.

[nnleaf]

I have tried rolling back Timeshift with no success, so it seems like it's another of Arch's packages that broke Timeshift?
I was having similar issues as you (2 rsync processes, no error messages, running indefinitely), then I wiped my backup disk clean and got an error like #589 .

I've ran -Syu quite a number of times already, so it would be difficult to try isolating which full system update broke Timeshift. Hopefully someone that recently broke timeshift can try isolating which package to hold an update for.

[ersterhernd]

Same problem here. Currently running 5.6.7-arch1-1 kernel and TimeShift hangs on the final 3 seconds. Rolling back to a previous snapshot fixes it. I have no idea what's causing the issue.

[ersterhernd]

Thanks!

Downgrade dhcpcd to 8.x.x fixed the TimeShift issue.

[svds86]

The 3rd solution (excluding /var/lib/dhcpcd) works for me, thanks!

[the-shank]

I recently started having this issue. I can confirm that the 3rd solution (excluding /var/lib/dhcpcd) did it for me too.

[dademiller360]

I uninstalled directly dhcpcd but nothing happened, timeshift stopped on an undefined folder around Documents, (home/user directory) any chance to understad wich file is it? I excluded the entire folder and it started working. thanks

[rubar-tech]

I use timeshift on Manjaro Linux, till now everything was working just fine but with the last rolling update of Manjaro, 1-2 days ago, this problem started with me too, I haven't tested any of possible solutions yet.

[rubar-tech]

The 3rd solution (excluding /var/lib/dhcpcd) works for me, thanks!

It didn't work for me, but timeshift just got updated, and now it works again