Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add override-lock to other options #47

Open
adambmedent opened this issue Aug 21, 2019 · 8 comments
Open

Add override-lock to other options #47

adambmedent opened this issue Aug 21, 2019 · 8 comments
Assignees
Labels
feature New feature or request

Comments

@adambmedent
Copy link

Benji has been going really well. However we just hit this.

(benji) [root@ceph-benji ~]# /usr/local/benji/bin/benji restore -f --sparse V0000001452 file:/benji-bunker/test.img
INFO: $ /usr/local/benji/bin/benji restore -f --sparse V0000001452 file:/benji-bunker/test.img
ERROR: AlreadyLocked: Version V0000001452 is already locked.

Anyway we can get --override-locks added to the restore option?

@elemental-lf elemental-lf self-assigned this Aug 22, 2019
@elemental-lf
Copy link
Owner

I'm not sure if adding an --override-locks option would be the right approach here. Could you please look into the locks table and send my the corresponding row data? That way we could figure out what operation acquired the lock. If the operation holding the lock is/was a backup then I'm not sure if a restore should be allowed at all as the resulting image would be incomplete. Or maybe it would be better to don't acquire the lock on restore and just output a warning when the version is locked.

(If you really need a restore of this version you can manually delete the corresponding row from the locks table. After collecting the info mentioned above of course...)

@adambmedent
Copy link
Author

I actually figure out how to delete the lock yesterday so I won't be able to provide that information.

However I can tell you that we hit the lock issue after ctrl+c out of a restore process.

@elemental-lf
Copy link
Owner

elemental-lf commented Aug 22, 2019

Okay, so it probably is a left-over of the interrupted restore process (seems that lock clean-up isn't working in all cases). I will have to think about this but I am currently leaning in the direction of not locking the version at all on restore and just issuing a warning.
EDIT: Another option would be to add a general "break locks" command.

@adambmedent
Copy link
Author

I have done a bit of testing and this is what I see.

If a ctrl+c out of a restore and let the cleanup run, all is well. However if I ctrl+c the restore and hit ctrl+c a couple more times, it also seems to kill that cleanup process. Not sure if that is something you can address or not.

@elemental-lf
Copy link
Owner

While it would be possible to try to catch or ignore these additional SIGINTs I don't think that it is really sustainable long-term. The locking on versions is mainly done to prevent removal of the version while on operation on it is in progress. I'm thinking about replacing the locking with a lease based system. That way things would clean themselves up automatically as soon as the lease expires.

@adambmedent
Copy link
Author

I like the sounds of that, seems like it would solve multiple issues.

@elemental-lf elemental-lf added the feature New feature or request label Nov 1, 2019
@wech71
Copy link
Contributor

wech71 commented Jan 21, 2020

Great! I just came here to report the same issue. This sounds like a good aproach.

But possibly an additional "force-unlock" command would be nice, depending on the intended lease-duration.

@elemental-lf
Copy link
Owner

My current plan is to go for a short lease duration (minutes) and renew the lease regularly while an operation is in progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants