> Op 14 mei 2016 om 11:53 schreef Ruben Kerkhof <ruben@xxxxxxxxxxxxxxxx>: > > > 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. > So, there is no ceph-mon.target on my system. Ceph 10.2.0-1xenial is installed. root@alpha:~# systemctl status ceph.target ● ceph.target - ceph target allowing to start/stop all ceph*@.service instances at once Loaded: loaded (/lib/systemd/system/ceph.target; enabled; vendor preset: enabled) Active: active since Sat 2016-05-14 14:20:27 CEST; 13min ago root@alpha:~# root@alpha:~# systemctl status ceph-mon.target ● ceph-mon.target Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) root@alpha:~# It is also not present: root@alpha:~# ls -l /lib/systemd/system/ceph* -rw-r--r-- 1 root root 315 Apr 21 00:28 /lib/systemd/system/ceph-create-keys@.service -rw-r--r-- 1 root root 205 Apr 21 00:28 /lib/systemd/system/ceph-disk@.service -rw-r--r-- 1 root root 581 Apr 21 00:28 /lib/systemd/system/ceph-mds@.service -rw-r--r-- 1 root root 808 Apr 21 00:28 /lib/systemd/system/ceph-mon@.service -rw-r--r-- 1 root root 669 Apr 21 00:28 /lib/systemd/system/ceph-osd@.service -rw-r--r-- 1 root root 551 Apr 21 00:28 /lib/systemd/system/ceph-radosgw@.service -rw-r--r-- 1 root root 128 Apr 21 00:28 /lib/systemd/system/ceph.target root@alpha:~# If I look in Ceph's source in the 'systemd' directory I indeed see ceph-mon.target, but also ceph-osd.target I copied ceph-mon.target from the source repo to /lib/systemd/system and enabled it afterwards. My monitors now start on boot. So this seems like a packaging issue? Wido > 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
 |