No scheduled snapshots while open, and no notification of failure

[aiqc]

I took 2 snapshots. Then I left the Timeshift app open so that I could see the scheduled snapshots coming in.

However, I came back a few hours later to find that Timeshift was not recording the hourly scheduled snapshots as expected.

I opened the logs and saw this in one of the hourly attempts:

[15:00:01] Main: check_dependencies()
[15:00:01] Another instance of this application is running (PID=25514)

So a few things come to mind:

• Timeshift doesn't work when timeshift is open? I'd prefer to leave it open as a reminder to take snapshots at important times and to add comments about changes to my build.
• Timeshift does not provide errors/ notifications of failed snapshots in the UI or OS alerts anywhere else.

• Ubuntu 22.04.3 (not Mint)
• Timeshift v21.09.1-1 (installed from default apt repo)

[aiqc]

I close Timeshift and come back an hour later to find that a successful snapshot has occured.

[svankirk]

I can verify this. I found out by losing a days work. :( This is an egregious bug for a backup program!!!! If it is a feature, then it needs to be very well documented

[rkarlsba]

Verified on Linux Mint 22.3

Keep in mind that it will block its own functionality merely by having the GUI opened, without telling the user. Whatever happens if the process is in a limbo, I don't know.

IMHO this is not a bug, it's a design flaw. I can somewhat understand it has to make sure no conflicting operations happen, but for traditional filesystems, that should be done in a separate process. For btrfs, it's already being done by btrfs itself. Using a huge lock on the whole program, GUI and all, is not a very good design, to put it bluntly.

Suggestions for a quick-and-dirty fix:

• For snapshottable filesystems like btrfs, remote the whole lock and make sure there are hooks into the filesystem to keep in sync with the snapshots on disk so that these are shown and can be manipulated correctly.
• For traditional filesystems, keep the lock, but only use it when an action is triggered.

Suggestions for a good and long-term fix:

• Rewrite the whole thing with separate server and GUI processes, since they serve very different roles. As for handling the lock(s), use the above quick-and-dirty suggestions as a start.

[ygerlach]

Rewrite the whole thing with separate server and GUI processes

i think that is a good idea. Creating a DBus interface allows us to have good integration within systemd and polkit, while also having good language bindings and integration for vala. Having timeshift as server/client app was something on my list for some time. I thought i wrote it somewhere but now i couldnt find the issue.
The main problem we may be having: If you want to restore a snapshot on a broken system you may need to run timeshift without a working dbus. So we probably still need to support a cli mode, that is direct without a server.

[rkarlsba]

Rewrite the whole thing with separate server and GUI processes

i think that is a good idea. Creating a DBus interface allows us to have good integration within systemd and polkit, while also having good language bindings and integration for vala. Having timeshift as server/client app was something on my list for some time. I thought i wrote it somewhere but now i couldnt find the issue. The main problem we may be having: If you want to restore a snapshot on a broken system you may need to run timeshift without a working dbus. So we probably still need to support a cli mode, that is direct without a server.

Sounds good to me. But having a CLI mode to directly work with the snapshots, will by no means exclude a client-server model. It'll just fullfill it in case of emergency.

And btw, if you then keep the lock, the CLI mode certainly wontt work if the daemon is running 😉

roy