Ceph » rgw

Trying to start the daemon in a RHEL box:

[ubuntu@magna123 configs]$ sudo service radosgw start
Redirecting to /bin/systemctl start  radosgw.service
Job for ceph-radosgw.service failed. See 'systemctl status ceph-radosgw.service' and 'journalctl -xn' for details.
[ubuntu@magna123 configs]$ echo $?
1

systemctl has no idea why it failed.

[ubuntu@magna123 configs]$ sudo systemctl status ceph-radosgw.service
ceph-radosgw.service - LSB: radosgw RESTful rados gateway
   Loaded: loaded (/etc/rc.d/init.d/ceph-radosgw)
   Active: failed (Result: exit-code) since Wed 2015-02-18 12:57:19 PST; 12s ago
  Process: 16160 ExecStart=/etc/rc.d/init.d/ceph-radosgw start (code=exited, status=1/FAILURE)

Feb 18 12:57:18 magna123 ceph-radosgw[16160]: Starting radosgw instance(s)...
Feb 18 12:57:19 magna123 ceph-radosgw[16160]: /bin/radosgw is not running.
Feb 18 12:57:19 magna123 systemd[1]: ceph-radosgw.service: control process exited, code=exited status=1
Feb 18 12:57:19 magna123 systemd[1]: Failed to start LSB: radosgw RESTful rados gateway.
Feb 18 12:57:19 magna123 systemd[1]: Unit ceph-radosgw.service entered failed state.

After enabling the log file location in ceph.conf it fails to write anything to it:

[ubuntu@magna123 configs]$ tail /var/log/radosgw/client.radosgw.magna.log
[ubuntu@magna123 configs]$

Adding a `-x` to the init script yielded the following in `/var/log/messages`:

Feb 20 13:42:25 magna123 ceph-radosgw: ++ ceph-conf -n client.radosgw.magna host
Feb 20 13:42:25 magna123 ceph-radosgw: + host=magna123.ceph.redhat.com
Feb 20 13:42:25 magna123 ceph-radosgw: ++ hostname -s
Feb 20 13:42:25 magna123 ceph-radosgw: + hostname=magna123
Feb 20 13:42:25 magna123 ceph-radosgw: + '[' magna123.ceph.redhat.com '!=' magna123 ']'

A few things that should be noted/fixed for this problem:

• The init script should write errors to the log file if configued otherwise to syslog (whatever location is the default for the distro)
• A user should not need to slap `-x` to the script to understand what is going on.
• Errors should be reported to systemctl (for systemctl distros) or find any other means to report back to the user