On Thu, May 12, 2016 at 2:16 PM, Wido den Hollander <wido@xxxxxxxx> wrote: > Hi, Hi Wido, > > I am setting up a Jewel cluster in VMs with Ubuntu 16.04. > > ceph version 10.2.0 (3a9fba20ec743699b69bd0181dd6c54dc01c64b9) > > After a reboot the Ceph Monitors don't start and I have to do so manually. I had a similar issue with Jewel on CentOS 7, but enabling ceph-mon.target fixed it for me. I deployed with ceph-deploy, which does enable ceph.target but not ceph-mon.target. Here's how it's supposed to work: $ systemctl list-dependencies ceph.target ceph.target ● └─ceph-mon.target ● └─ceph-mon@ams1-ceph01-mon01.service So ceph.target pulls in ceph-mon.target which pulls in the actual service. Now ams1-ceph01-mon01.service wants the ceph-create-keys@%i.service: $ systemctl list-dependencies ceph-mon@ams1-ceph01-mon01.service ceph-mon@ams1-ceph01-mon01.service ● ├─-.mount ● ├─ceph-create-keys@ams1-ceph01-mon01.service ● ├─system-ceph\x2dmon.slice Note, this is a Wants=, not a Requires=, so ceph-create-keys is allowed to fail, so it shouldn't block ceph-mon from starting. Then the question is indeed, why did it fail and did it even start? What does systemctl status for that service show for you? $ systemctl status ceph-create-keys@ams1-ceph01-mon01.service ● ceph-create-keys@ams1-ceph01-mon01.service - Ceph cluster key creator task Loaded: loaded (/usr/lib/systemd/system/ceph-create-keys@.service; static; vendor preset: disabled) Active: inactive (dead) Condition: start condition failed at Thu 2016-04-21 09:18:45 CEST; 3 weeks 2 days ago In my case this is a working cluster, so the keyring is already there and the service doesn't need to start (ConditionPathExists=!/var/lib/ceph/bootstrap-mds/ceph.keyring) Kind regards, Ruben Kerkhof _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |