stick client PID in client_metadata
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.)
#1 Updated by Patrick Donnelly about 6 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.
#3 Updated by Greg Farnum about 6 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.