[GH-ISSUE #2916] backup.lock shouldn't exist on persistant storage #2081

New issue

Open

opened 2026-02-27 03:00:45 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 03:00:45 +03:00

Owner

Originally created by @duffyjp on GitHub (Jun 4, 2020).
Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/2916

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.

Originally created by @duffyjp on GitHub (Jun 4, 2020). Original GitHub issue: https://github.com/GameServerManagers/LinuxGSM/issues/2916 ## 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.

kerem added the

type: bug

command: backup

Atomic

labels

2026-02-27 03:00:45 +03:00

kerem commented

2026-02-27 03:00:46 +03:00

Author

Owner

@issue-label-bot[bot] commented on GitHub (Jun 4, 2020):

Issue-Label Bot is automatically applying the label type: bug to this issue, with a confidence of 0.89. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@issue-label-bot[bot] commented on GitHub (Jun 4, 2020): 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](https://github.com/marketplace/issue-label-bot), [dashboard](https://mlbot.net/data/GameServerManagers/LinuxGSM) and [code](https://github.com/hamelsmu/MLapp) for this bot.

kerem commented

2026-02-27 03:00:46 +03:00

Author

Owner

@dgibbs64 commented on GitHub (Jul 13, 2020):

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

@dgibbs64 commented on GitHub (Jul 13, 2020): 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

kerem commented

2026-02-27 03:00:46 +03:00

Author

Owner

@duffyjp commented on GitHub (Jul 17, 2020):

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

@duffyjp commented on GitHub (Jul 17, 2020): 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