The in-memory options do not appear to differ:
[root@ceph1 ceph]# ceph daemon mgr.ceph1 config show | grep scrub
"mds_max_scrub_ops_in_progress": "5",
"mon_scrub_inject_crc_mismatch": "0.000000",
"mon_scrub_inject_missing_keys": "0.000000",
"mon_scrub_interval": "86400",
"mon_scrub_max_keys": "100",
"mon_scrub_timeout": "300",
"mon_warn_not_deep_scrubbed": "0",
"mon_warn_not_scrubbed": "0",
"osd_debug_deep_scrub_sleep": "0.000000",
"osd_deep_scrub_interval": "604800.000000",
"osd_deep_scrub_keys": "1024",
"osd_deep_scrub_large_omap_object_key_threshold": "2000000",
"osd_deep_scrub_large_omap_object_value_sum_threshold": "1073741824",
"osd_deep_scrub_randomize_ratio": "0.150000",
"osd_deep_scrub_stride": "524288",
"osd_deep_scrub_update_digest_min_age": "7200",
"osd_max_scrubs": "1",
"osd_op_queue_mclock_scrub_lim": "0.001000",
"osd_op_queue_mclock_scrub_res": "0.000000",
"osd_op_queue_mclock_scrub_wgt": "1.000000",
"osd_requested_scrub_priority": "120",
"osd_scrub_auto_repair": "false",
"osd_scrub_auto_repair_num_errors": "5",
"osd_scrub_backoff_ratio": "0.660000",
"osd_scrub_begin_hour": "0",
"osd_scrub_begin_week_day": "0",
"osd_scrub_chunk_max": "25",
"osd_scrub_chunk_min": "5",
"osd_scrub_cost": "52428800",
"osd_scrub_during_recovery": "false",
"osd_scrub_end_hour": "24",
"osd_scrub_end_week_day": "7",
"osd_scrub_interval_randomize_ratio": "0.500000",
"osd_scrub_invalid_stats": "true",
"osd_scrub_load_threshold": "0.500000",
"osd_scrub_max_interval": "604800.000000",
"osd_scrub_max_preemptions": "5",
"osd_scrub_min_interval": "86400.000000",
"osd_scrub_priority": "5",
"osd_scrub_sleep": "0.000000",
[root@ceph1 ceph]#
I've checked the restart time of the mgr, it looks like it was restarted early on during the upgrade process.
[root@ceph1 ceph]# systemctl status ceph-mgr@ceph1 -l
● ceph-mgr@ceph1.service - Ceph cluster manager daemon
Loaded: loaded (/usr/lib/systemd/system/ceph-mgr@.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2019-01-03 08:04:42 GMT; 1 day 6h ago
Main PID: 230099 (ceph-mgr)
CGroup: /system.slice/system-ceph\x2dmgr.slice/ceph-mgr@ceph1.service
└─230099 /usr/bin/ceph-mgr -f --cluster ceph --id ceph1 --setuser ceph --setgroup ceph
Jan 03 08:04:42 ceph1.iop.kcl.ac.uk systemd1: Started Ceph cluster manager daemon.
Jan 03 08:04:42 ceph1.iop.kcl.ac.uk ceph-mgr230099: 2019-01-03 08:04:42.442 7f7c2adb9380 -1 deliberately leaking some memory
Jan 03 08:04:59 ceph1.iop.kcl.ac.uk ceph-mgr230099: 2019-01-03 08:04:59.293 7f7c1718c700 -1 received signal: Hangup from (PID: 230676) UID: 0
Jan 03 08:04:59 ceph1.iop.kcl.ac.uk ceph-mgr230099: 2019-01-03 08:04:59.314 7f7c1718c700 -1 received signal: Hangup from pkill -1 -x ceph-mon|ceph-mgr|ceph-mds|ceph-osd|ceph-fuse|radosgw (PID: 230677) UID: 0
Jan 03 11:34:30 ceph1.iop.kcl.ac.uk ceph-mgr230099: ignoring --setuser ceph since I am not root
Jan 03 11:34:30 ceph1.iop.kcl.ac.uk ceph-mgr230099: ignoring --setgroup ceph since I am not root
Jan 03 11:34:30 ceph1.iop.kcl.ac.uk ceph-mgr230099: 2019-01-03 11:34:30.367 7f59613d3380 -1 deliberately leaking some memory
Jan 04 03:31:01 ceph1.iop.kcl.ac.uk ceph-mgr230099: 2019-01-04 03:31:01.936 7f594da2f700 -1 received signal: Hangup from killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw (PID: 242857) UID: 0
Jan 04 03:31:01 ceph1.iop.kcl.ac.uk ceph-mgr230099: 2019-01-04 03:31:01.963 7f594da2f700 -1 received signal: Hangup from pkill -1 -x ceph-mon|ceph-mgr|ceph-mds|ceph-osd|ceph-fuse|radosgw (PID: 242858) UID: 0
[root@ceph1 ceph]#
I've just restarted it and the warning message has disappeared.
[root@ceph3 log]# ceph status
cluster:
id: e474ffde-40fd-44c2-aa4d-753dd4dd0761
health: HEALTH_OK
services:
mon: 3 daemons, quorum ceph1,ceph2,ceph3
mgr: ceph1(active), standbys: ceph2, ceph3
mds: cephfs-nan-1/1/1 up {0=ceph3=up:active}, 2 up:standby
osd: 36 osds: 36 up, 36 in
data:
pools: 2 pools, 1280 pgs
objects: 45.42 M objects, 29 TiB
usage: 51 TiB used, 276 TiB / 327 TiB avail
pgs: 1279 active+clean
1 active+clean+scrubbing+deep
io:
client: 416 KiB/s rd, 17 MiB/s wr, 26 op/s rd, 109 op/s wr
[root@ceph3 log]#
Here is the order in which the patches were applied:
Jan 03 08:13:08 Updated: librados2.x86_64 2:13.2.3-0.el7
Jan 03 08:13:08 Updated: python-rados.x86_64 2:13.2.3-0.el7
Jan 03 08:13:08 Updated: librbd1.x86_64 2:13.2.3-0.el7
Jan 03 08:13:08 Updated: libcephfs2.x86_64 2:13.2.3-0.el7
Jan 03 08:13:09 Updated: librgw2.x86_64 2:13.2.3-0.el7
Jan 03 08:13:09 Updated: python-rgw.x86_64 2:13.2.3-0.el7
Jan 03 08:13:09 Updated: python-cephfs.x86_64 2:13.2.3-0.el7
Jan 03 08:13:09 Updated: python-rbd.x86_64 2:13.2.3-0.el7
Jan 03 08:13:09 Updated: libradosstriper1.x86_64 2:13.2.3-0.el7
Jan 03 08:13:11 Updated: ceph-common.x86_64 2:13.2.3-0.el7
Jan 03 08:13:12 Updated: ceph-base.x86_64 2:13.2.3-0.el7
Jan 03 08:13:35 Updated: ceph-selinux.x86_64 2:13.2.3-0.el7
Jan 03 08:13:36 Updated: ceph-mgr.x86_64 2:13.2.3-0.el7
Jan 03 08:13:36 Updated: ceph-mds.x86_64 2:13.2.3-0.el7
Jan 03 08:13:37 Updated: ceph-mon.x86_64 2:13.2.3-0.el7
Jan 03 08:13:38 Updated: ceph-osd.x86_64 2:13.2.3-0.el7
Jan 03 08:13:38 Updated: ceph.x86_64 2:13.2.3-0.el7
Jan 03 08:13:39 Updated: ceph-radosgw.x86_64 2:13.2.3-0.el7
Jan 03 08:57:30 Erased: yum-cron-3.4.3-161.sl7.noarch
Jan 03 15:03:06 Installed: zabbix-release-3.2-1.el7.noarch
Jan 03 15:04:09 Installed: zabbix-agent-3.2.11-1.el7.x86_64
Jan 03 15:04:35 Installed: zabbix-sender-3.2.11-1.el7.x86_64
I guess this wouldn't normally be an issue, I would expect to run an update followed by a server reboot.
Chris