Hi, >> And then I start the process, and it starts fine. http://pastebin.com/TPzNth6P >> I even see one active tcp connection to a mon from that process. >> >> But the osd never becomes "up" or do anything ... > > I suppose there are error messages in logs somewhere regarding the fact that monitors and other OSDs expected OSD 3 to be in a state that has been lost. Or is there nothing at all ? Where should I be looking ? I posted the log above with "debug osd = 10" and don't seen anything abnormal. On the mon logs, the only thing that happens when starting osd.3 is : 2014-07-01 18:17:06.947065 7f52d6894700 0 mon.a at 0(leader) e8 handle_command mon_command({"prefix": "osd crush create-or-move", "args": ["host=ceph", "root=default"], "id": 3, "weight": 0.03} v 0) v1 2014-07-01 18:17:06.947205 7f52d6894700 0 mon.a at 0(leader).osd e1128 create-or-move crush item name 'osd.3' initial_weight 0.03 at location {host=ceph,root=default} which is triggered by the startup script and not even the OSD itself. Cheers, Sylvain