Bug #39443
open"ceph daemon" does not support ceph args
0%
Description
This works:
ceph daemon osd.0 perf dump
But this fails:
adonis:~/ceph/ceph/build% ceph --debug-ms=0 daemon osd.0 perf dump no valid command found; 10 closest matches: pg stat pg getmap pg dump {all|summary|sum|delta|pools|osds|pgs|pgs_brief [all|summary|sum|delta|pools|osds|pgs|pgs_brief...]} pg dump_json {all|summary|sum|pools|osds|pgs [all|summary|sum|pools|osds|pgs...]} pg dump_pools_json pg ls-by-pool <poolstr> {<states> [<states>...]} pg ls-by-primary <osdname (id|osd.id)> {<int>} {<states> [<states>...]} pg ls-by-osd <osdname (id|osd.id)> {<int>} {<states> [<states>...]} pg ls {<int>} {<states> [<states>...]} pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>} Error EINVAL: invalid command adonis:~/ceph/ceph/build% ceph -k ./keyring daemon osd.0 perf dump no valid command found; 10 closest matches: pg stat pg getmap pg dump {all|summary|sum|delta|pools|osds|pgs|pgs_brief [all|summary|sum|delta|pools|osds|pgs|pgs_brief...]} pg dump_json {all|summary|sum|pools|osds|pgs [all|summary|sum|pools|osds|pgs...]} pg dump_pools_json pg ls-by-pool <poolstr> {<states> [<states>...]} pg ls-by-primary <osdname (id|osd.id)> {<int>} {<states> [<states>...]} pg ls-by-osd <osdname (id|osd.id)> {<int>} {<states> [<states>...]} pg ls {<int>} {<states> [<states>...]} pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>} Error EINVAL: invalid command adonis:~/ceph/ceph/build% CEPH_ARGS='--debug-ms=0' ceph daemon osd.0 perf dump Invalid command: Unexpected argument '--debug-ms=0' perf dump {<logger>} {<counter>} : dump perfcounters value admin_socket: invalid command
Updated by Greg Farnum almost 5 years ago
I'm not sure this is a problem — "ceph daemon" is just for talking to a local Unix socket; it doesn't engage in any of the normal ceph boot up process or use the network or anything. Setting debug_ms on it is totally pointless; was that just an example and there's some argument which would be meaningful?
Updated by Mykola Golub almost 5 years ago
Sure, 'debug_ms' was just an example to illustrate the problem. Yes the most (if not all) ceph args do not make sense for `ceph daemon` but still can be specified causing unexpected (hard to debug) behavior.
In our case, a user reported `ceph daemon` was not working and it required considerable time to figure out, that the issue was that they had an alias ceph='ceph -k keyring'.
The alias like this is probably not a good idea in any case, so one could blame the user, but having at least not confusing error output would be very useful.
Another case, `CEPH_ARGS` environment variable, is probably a more valid example than the alias. It is not supposed to make `ceph deamon` not work if set.
Updated by Nathan Cutler over 3 years ago
- Backport changed from nautilus,mimic,luminous to octopus,nautilus,mimic,luminous
Updated by Nathan Cutler over 3 years ago
- Backport changed from octopus,nautilus,mimic,luminous to octopus,nautilus