backup.lock shouldn't exist on persistant storage
User Story
It turns out my cron scheduled backups haven't been running due to a stale lock file. I recommend changing the default location of the backup.lock file to tmpfs so it won't survive a reboot.
Basic info
- Distro: [Ubuntu 20.04]
- Game: [Minecraft]
- Command: [backup]
- LinuxGSM version: [v20.3.3]
Further Information
- Instead of
./lgsm/lock/probably/run/lock/ - Alternatively , you could store the pid of the backup command in the lock file and check that it still exists.
To Reproduce
Steps to reproduce the behaviour:
- have a stale backup.lock from 2 months ago.
- cron the backup command nightly
- enjoy no backups when you need it (I know, my fault for not checking).
Expected behaviour
- A reboot should clear the lock, as the backup process would also not survive a reboot.
Issue-Label Bot is automatically applying the label type: bug to this issue, with a confidence of 0.89. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
The lock file remains because a backup was cancelled partway through. The solution might be for backup to clear stale locks automatically after a period of time say 1 hour, it clould also check that a backup is not still running as part of this check
Looking at this again, it may be smart to keep the lock file in a relative path as you have it, as that will make things a lot easier if you have two instances of lgsm running on the same host.
What I propose is that we use backup.pid instead of backup.lock and store the backup's process id in it on creation. Should the backup command be invoked while backup.pid still exists on disk, can can check ps to see if the process is still running and abort if so.
I've implemented this in Ruby in the past. I can put together a PR if you think it would be merged.
https://github.com/duffyjp/rb2db/blame/master/lib/rb2db.rb