Project

General

Profile

Bug #2481

ceph tell has almost no error reporting

Added by Dan Mick over 11 years ago. Updated about 11 years ago.

Status:
Won't Fix
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
No
Severity:
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

fumbling around as a noob, I tried all of:

ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs 'debug osd = 0'
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs 'debug = 0'
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs 'debug osd = 0'
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs 'debug osd = 0'
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell osd.1 injectargs --debug_osd 0
osd.0 not up
ubuntu@burnupi50:/etc/ceph$ ceph osd tell osd.1 injectargs --debug_osd 0
osd.0 not up
ubuntu@burnupi50:/etc/ceph$ ceph osd tell osd.1 injectargs --debug_osd 0
osd.0 not up
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs --debug_osd 0
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs --debug-osd 0
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell osd.1 injectargs --debug-osd 0
osd.0 not up
ubuntu@burnupi50:/etc/ceph$ ceph osd injectargs 1 --debug-osd 0
unknown command injectargs
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs --debug-osd 0
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs --debug_osd 0
ok
ubuntu@burnupi50:/etc/ceph$ ceph osd tell 1 injectargs '--debug_osd 0'
ok

Only the last one has any useful effect. It seems like some sort of error reporting better than
'ok' would be possible.

History

#1 Updated by Greg Farnum over 11 years ago

This is actually a lot harder than you'd think — "ceph tell" works by sending a message to the monitors, which is then forwarded to the appropriate location, which takes the reported action. But it's a broadcast, not anything stateful, so there's no way for the receiving daemon to tell the monitor "umm, that's a nonsense string".

Really ceph tell should talk directly to whoever it needs to, rather than making the monitor do it. Probably modeled after the monitor commands interface; as messy as that is it's at least easy to add functionality and to parse.

#2 Updated by Sage Weil over 11 years ago

Greg Farnum wrote:

This is actually a lot harder than you'd think — "ceph tell" works by sending a message to the monitors, which is then forwarded to the appropriate location, which takes the reported action. But it's a broadcast, not anything stateful, so there's no way for the receiving daemon to tell the monitor "umm, that's a nonsense string".

Really ceph tell should talk directly to whoever it needs to, rather than making the monitor do it. Probably modeled after the monitor commands interface; as messy as that is it's at least easy to add functionality and to parse.

It does, if you use the 'ceph tell osd.N ...' syntax. Then you block, and get the response.

#3 Updated by Sage Weil about 11 years ago

  • Status changed from New to Won't Fix

this should get cleaned up with whatever refactor we do with the api work, but not worth spending time on individually until then.

Also available in: Atom PDF