From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <20180925164405.GA10635@redhat.com> <20180927173550.GB2706@redhat.com> <20180928143203.GA5724@redhat.com> In-Reply-To: <20180928143203.GA5724@redhat.com> From: Damon Wang Date: Sat, 29 Sep 2018 02:13:38 +0800 Message-ID: Subject: Re: [linux-lvm] [lvmlockd] recovery lvmlockd after kill_vg Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: David Teigland Cc: LVM general discussion and development It's really help, I noticed "sanlock client renewal" returns practical information, but not noticed "sanlock client status -D", the later is what I exactly want, thanks! Damon On Fri, Sep 28, 2018 at 10:32 PM David Teigland wrote: > > On Fri, Sep 28, 2018 at 11:14:35AM +0800, Damon Wang wrote: > > > as the manual says, it should deactivate volumes and drop lockspace as > > quick as possible, > > A year ago we discussed a more automated solution for forcing a VG offline > when its sanlock lockspace was shut down: > > https://www.redhat.com/archives/lvm-devel/2017-September/msg00011.html > > The idea was to forcibly shut down LVs (using dmsetup wipe_table) in the > VG when the kill_vg happened, then to automatically do the 'lvmlockctl > --drop' when the LVs were safely shut down. There were some loose ends > around integrating this solution that I never sorted out, so it's remained > on my todo list. > > > TTY can get a message, but it's not a good way to listen or monitor, so I > > run vgck periodically and parse its stdout and stderr, once "sanlock lease > > storage failure" or > > something unusual happens, an alert will be triggered and I'll do some > > check(I hope all this process can be automatically). > > If you are specifically interested in detecting this lease timeout > condition, there are some sanlock commands that can give you this info. > You can also detect ahead of time that a VG's lockspace is getting close > the threshold. I can get back to you with more specific fields to look > at, but for now take a look at 'sanlock client renewal' and some of the > internal details that are printed by 'sanlock client status -D'. > > Dave