osd: install async signal handlers after init()

The orderly shutdown in OSD assumes init() has completed.

Signed-off-by: Sage Weil <sage@inktank.com>
osd: do not assume we have an osdmap in prepare_to_stop

Signed-off-by: Sage Weil <sage@inktank.com>
mon: install signal handlers after init

Signed-off-by: Sage Weil <sage@inktank.com>
mds: install signal handlers after init

Signed-off-by: Sage Weil <sage@inktank.com>
mds: reorder suicide/shutdown a bit

* shutdown msgr last
* stop timer quickly, in case there are other events

Signed-off-by: Sage Weil <sage@inktank.com>
mon: shutdown: remove sessions under mon->lock

Signed-off-by: Sage Weil <sage@inktank.com>
mds: put g_ceph_context on shutdown

This makes us shut down lots of threads.

Signed-off-by: Sage Weil <sage@inktank.com>
mon, mds, osd: add early SIGTERM injection

This makes it easy to identify problems with (early) shutdown with a
loop like

 while [ ! -e core ] ; do ./ceph-mds -i a -c ceph.conf -f ; done

and a vstart cluster.

Signed-off-by: Sage Weil <sage@inktank.com>
ceph.in: reject --admin-daemon so it can't do harm

Fixes: #3944
Signed-off-by: Dan Mick <dan.mick@inktank.com>
ceph-monstore-tool: dump paxos transactions

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: accepted_pn_from has no semantic meaning

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: only share uncommitted value if it is next

We may have an uncommitted value from our perspective (it is our lc + 1)
when the collector has a much larger lc (because we have been out for
the last few rounds).  Only share an uncommitted value if it is in fact
the next value.

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: only learn uncommitted value if it is in the future

If an older peer sends an uncommitted value, make sure we only take it
if it is in the future, and at least as new as any current uncommitted
value.

(Prior to the previous patch, peers could send values from long-past
rounds.  The pn values are also bogus.)

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: debug ignored uncommitted values

Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: fix pn for uncommitted value during collect/last phase

During the collect/last exchange, peers share any uncommitted values
with the leader.  They are supposed to also share the pn under which
that value was accepted, but were instead using the just-accepted pn
value.  This effectively meant that we *always* took the uncommitted
value; if there were multiples, which one we accepted depended on what
order the LAST messages arrived, not which pn the values were generated
under.

The specific failure sequence I observed:

 - collect
  - learned uncommitted value for 262 from myself
  - send collect with pn 901
 - got last with pn 901 (incorrect) for 200 (old) from peer
  - discard our own value, remember the other
 - finish collect phase
  - ignore old uncommitted value

Fix this by storing a pending_v and pending_pn value whenever we accept
a value.  Use this to send an appropriate pn value in the LAST reply
so that the leader can make it's decision about which uncommitted value
to accept based on accurate information.  Also use it when we learn
the uncommitted value from ourselves.

We could probably be more clever about storing less information here,
for example by omitting pending_v and clearing pending_pn at the
appropriate point, but that would be more fragile.  Similarly, we could
store a pn for *every* commit if we wanted to lay some groundwork for
having multiple uncommitted proposals in flight, but I don't want to
speculate about what is necessary or sufficient for a correct solution
there.

Fixes: #5698
Backport: cuttlefish, bobtail
Signed-off-by: Sage Weil <sage@inktank.com>
mon/Paxos: add failure injection points

Signed-off-by: Sage Weil <sage@inktank.com>
rgw: send data back when copying object

Currently doing it only when copying between regions. This is
needed so that the operation doesn't time out (as it can take
a long time and the web server may just hang on us since we're
not sending any data).
This is configurable and can be disabled. Currently only implemented
for S3.

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
rgw: dump progress through swift object copy

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
rgw: add some comments

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
PendingReleaseNotes: update about new rgw copy obj response

Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>