Bug 1944009

Summary:	[GSS] "RGWReshardLock::lock failed to acquire lock on reshard.0000000002 ret=-16" messages are reported in rgw log
Product:	[Red Hat Storage] Red Hat Ceph Storage	Reporter:	hhuan
Component:	RGW	Assignee:	J. Eric Ivancich <ivancich>
Status:	CLOSED ERRATA	QA Contact:	Vidushi Mishra <vimishra>
Severity:	medium	Docs Contact:	Ranjini M N <rmandyam>
Priority:	unspecified
Version:	4.0	CC:	agunn, cbodley, ceph-eng-bugs, gsitlani, kbader, kdreyer, mbenjamin, mkasturi, rmandyam, vereddy
Target Milestone:	---
Target Release:	5.1
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	ceph-16.2.6-1.el8cp	Doc Type:	Enhancement
Doc Text:	.Lock contention messages from the Ceph Object Gateway reshard queue are marked as informational Previously, when the Ceph Object Gateway failed to get a lock on a reshard queue, the output log entry would appear to be an error causing concern to customers. With this release, the entries in the output log appear as informational and are tagged as “INFO:”.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-04-04 10:19:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2031073

Comment 3 J. Eric Ivancich 2021-04-14 17:07:13 UTC

So to more directly address customer, locks are a way for processes running in parallel to coordinate their access to shared objects/data. We would not want each of the RGW processes to simultaneously process the same reshard log, so the first one to try acquires the lock, the second one is locked out for the duration, and finally the first one releases the lock.

The customer clearly diagnosed this when they write: "Enable rgw debug log on the first rgw node in test env, find that the error msg is logged when another RGW daemon already acquired lock for reshard.000000000x:"

So the links to an analogous situation with LC (lifecycle) logs are relevant in that although based on a different subsystem of RGW, it's ultimately the same underlying issue.

I think the best course is to mark these messages INFOs rather than WARNINGs or ERRORs, so they don't raise unnecessary concern. If that's the case, remaining at log level 0 would not be an issue.

I'll put together a fix and target it for 5.1.

Eric

Comment 5 J. Eric Ivancich 2021-04-14 20:20:55 UTC

The upstream PR to address this can be found at https://github.com/ceph/ceph/pull/40862 .

Comment 6 J. Eric Ivancich 2021-04-14 20:46:27 UTC

The commit used from the pr linked to in comment #4 is 6d3dee37791ad427a3435c493a1d7874ba075674 .

Comment 21 errata-xmlrpc 2022-04-04 10:19:55 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat Ceph Storage 5.1 Security, Enhancement, and Bug Fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:1174