Project

General

Profile

Feature #17276

stick client PID in client_metadata

Added by Greg Farnum almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Administration/Usability
Target version:
-
Start date:
09/14/2016
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
Reviewed:
Affected Versions:
Component(FS):
Labels (FS):
Pull request ID:

Description

As best I can tell, we no longer provide any way for an admin to backtrack from a misbehaving client session to a specific PID, which makes debugging hard in situations that have multiple clients on a single box.

(In the past, the pid was used for the messenger nonce, but that got killed.)

History

#1 Updated by Patrick Donnelly almost 3 years ago

I will take this as I've been wanting it for my performance work.

I'm also wondering if you think it'd be useful to have a UUID for each running client/mds daemon (probably not a persistent UUID) that can be used to uniquely identify a daemon instance. This would also be useful for my database of performance values. Right now I'm using asok path names with PIDs (/var/run/ceph/ceph-client-$pid.asok) to distinguish clients which sucks.

#2 Updated by Patrick Donnelly almost 3 years ago

  • Assignee set to Patrick Donnelly

#3 Updated by Greg Farnum almost 3 years ago

There's already a GID (just an increasing integer) that the monitor uniquely associates with each client session — I guess that's not persistent across a whole process lifetime if it changes monitors, but it's probably good enough to get started with if you can dig out where that is.

#4 Updated by Patrick Donnelly almost 3 years ago

  • Status changed from New to Need Review

#5 Updated by Patrick Donnelly almost 3 years ago

Testing an email filter. Please ignore...

#6 Updated by Patrick Donnelly almost 3 years ago

  • Status changed from Need Review to Resolved

Also available in: Atom PDF