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

Global lock failed: held by other host #132

Open
liyuanchaoCh opened this issue Nov 27, 2023 · 6 comments
Open

Global lock failed: held by other host #132

liyuanchaoCh opened this issue Nov 27, 2023 · 6 comments

Comments

@liyuanchaoCh
Copy link

image
Hello, excuse me, how can I solve the "Global lock failed: held by other host " problem? How can I know which host holds the global lock?

@zkabelac
Copy link

zkabelac commented Nov 27, 2023

You can try to play with 'lvmlockctl -i' command.

There is not very trivial way to tell 'which' other host holds the lock - important for a machine is to 'know' some other machine holds the lock.

To decode the host - you need to know 'mapping' - so in practice it might be quite similar to check which machine really owns the lock.

@liyuanchaoCh
Copy link
Author

You can try to play with 'lvmlockctl -i' command.

There is not very trivial way to tell 'which' other host holds the lock - important for a machine is to 'know' some other machine holds the lock.

To decode the host - you need to know 'mapping' - so in practice it might be quite similar to check which machine really owns the lock.
So how should I deal with "Global lock failed: held by other host" to create vg with vgcreate?

@teigland
Copy link
Contributor

It looks like you're using sanlock. You need to check each host to find the command that is holding the global lock. On each host run: "lvmlockctl -i" and "sanlock status". On the host with a command holding the global lock, those commands will show something like this:

$ lvmlockctl -i
...
LK GL sh ver 0 pid 18058 (vgs)

$ sanlock status
...
r lvm_ss:GLLK:/dev/mapper/ss-lvmlock:68157440:SH p 17794

This indicates that pid 17794 (a 'vgs' command) is holding the global lock.

The global lock should not be held for a long time, so perhaps the pid is hung while holding the lock. If you find a hung command, you might want to check what it's doing before killing it.

@liyuanchaoCh
Copy link
Author

It looks like you're using sanlock. You need to check each host to find the command that is holding the global lock. On each host run: "lvmlockctl -i" and "sanlock status". On the host with a command holding the global lock, those commands will show something like this:

$ lvmlockctl -i
...
LK GL sh ver 0 pid 18058 (vgs)

$ sanlock status
...
r lvm_ss:GLLK:/dev/mapper/ss-lvmlock:68157440:SH p 17794

This indicates that pid 17794 (a 'vgs' command) is holding the global lock.

The global lock should not be held for a long time, so perhaps the pid is hung while holding the lock. If you find a hung command, you might want to check what it's doing before killing it.

Thanks. Does "GLLK" here mean holding global lock?

@teigland
Copy link
Contributor

"GLLK" is the sanlock resource name that lvmlockd uses for the global lock. If sanlock status prints the line, it means that the lock is currently held.

(One minor correction to what I wrote in the previous comment: the pid of the vgs command displayed by lvmlockctl is 18058. The "p 17794" displayed by sanlock status refers to the pid of the lvmlockd daemon.)

@liyuanchaoCh
Copy link
Author

"GLLK" is the sanlock resource name that lvmlockd uses for the global lock. If sanlock status prints the line, it means that the lock is currently held.

(One minor correction to what I wrote in the previous comment: the pid of the vgs command displayed by lvmlockctl is 18058. The "p 17794" displayed by sanlock status refers to the pid of the lvmlockd daemon.)

ok, thanks a lot

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

No branches or pull requests

3 participants