On Sun, Sep 2, 2018 at 12:43 AM, Mykola Golub <to.my.trociny@xxxxxxxxx> wrote: > On Sat, Sep 01, 2018 at 10:24:26PM -0500, Alex Litvak wrote: > >> 2018-09-01 20:21:22.026 7fe2dffff700 -1 set_mon_vals failed to set >> admin_socket = /var/run/ceph/$name.$pid.asok: Configuration option >> 'admin_socket' may not be modified at runtime > > It looks you added admin_socket option to the monitor configuration > database, either explicitely calling something like > > ceph config set client admin_socket ... > > or via assimilate-conf. This option does not make sence in the monitor > configuration database, as the client or daemon connects to the > monitor after the admin socket is created. You need to keep it in the > config file. That is why your see the warning. It is harmless, and you > can get rid of it by removing admin_socket from the database. Something else seems wrong here. It might be that the options are set in the global section and we didn't expect/test for that, but I don't think we should be warning so generically on every client on such things either. That's a serious UX issue and we already have mechanisms for seeing diffs in running daemons on the monitor itself. Or is there some reason that we're attempting to set every option and then spewing to stdout if we expectedly fail to do so? -Greg > For this > run > > ceph config dump | grep admin_socket > > to get the list of WHO this option has been added to. And then for > every WHO run: > > ceph config rm $WHO admin_socket > > In your case I assume it will be at least: > > ceph config rm client admin_socket > ceph config rm client.libvirt admin_socket > > The same is for other options you see the warnings for. I assume they > were added by assimilate-conf and this looks like a bug to me. > > [1] http://docs.ceph.com/docs/master/rados/configuration/ceph-conf/#monitor-configuration-database > > -- > Mykola Golub
