There were some accidental reverts, fixes, re-reverts,
and follow-on changes that are hard to follow and in the
end did not include what we want. Merge it all together.
Signed-off-by: Sage Weil <sage@redhat.com>
Rely on dynamic initialization instead. Linking lttng in this way had
the unfortunate side effect of causing radosgw to segfault (when
daemonized) during sigterm processing (ie. during lttng_ust_exit()).
This was originally removed in 638738f, but accidentally re-added via
5f61d36.
Signed-off-by: Karol Mroz <kmroz@suse.com>
Explicitly unlock to prevent a client from accidentally blacklisting
itself when retrying the lock.
Fixes: http://tracker.ceph.com/issues/15709
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
These codes are not applicable any more,
and removing unnecessary code is always the preferred option.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Delay injection was missing from a few spots, also, DelayedDelivery
was added.
Fixes: http://tracker.ceph.com/issues/15372
Signed-off-by: Piotr Dałek <piotr.dalek@ts.fujitsu.com>
In the new world, a standby replay daemon which
is actively replaying has its rank set. In the old
world it did not: map this during the upgrade/downgrade
paths in decode/encode.
Fixes: http://tracker.ceph.com/issues/15591
Signed-off-by: John Spray <john.spray@redhat.com>
Principally to tell people how to configure
standby, but more generally as a place to define
our terms for GIDs etc.
Signed-off-by: John Spray <john.spray@redhat.com>
This used to use an arcane set of constants
in standby_for_rank, combined with daemons sometimes
sending requests to enter state STANDBY_REPLAY.
Simplify this so that there is only one place we
put daemons into standby replay, and that is
in tick->maybe_promote_staandby.
There is a behavioural change in here, which is
that we used to sometimes promote standbys to
be standby-replay, even if they didn't have
"standby replay = true", when they did have
a standby_for_rank or standby_for_name set.
I'm calling that a bug, and making it so that
daemons will only go into standby-replay if
"standby replay = true" is set.
Signed-off-by: John Spray <john.spray@redhat.com>
So that daemons can explicitly say that they
want to be standby replay, instead of using
magic standby_for_rank values.
Because in some cases daemons would indicate this
with a beacon requesting STANDBY_REPLAY state, we
also munge these during decode to be normal STANDBY
requests with standby_replay=true.
Signed-off-by: John Spray <john.spray@redhat.com>
This predated cephfs-journal-tool. Don't bother
with any backwards-compatibility mechanisms here, as
it was a seriously niche undocumented thing.
On the off chance that someone ran an old ceph-mds against
a newer ceph-mon with oneshot enabled, it shouldn't break
anything, it just won't do what they want.
Signed-off-by: John Spray <john.spray@redhat.com>
The invoke async operation state machine can complete before the
owner lock is released. Use a stack reference to prevent
use-after-free.
Fixes: http://tracker.ceph.com/issues/15690
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
there is chance that the sync_entry() gets signaled in the
WaitInterval(max_interval) call because of sync_cond.Signal() call after
"stop = true" in umount(), so without this change, sync_entry() will
continue wait until min_interval is reached. this forces umount() to
wait even it has called d_force_sync(), and hence slows down the
progress of umount(). so we need to check for `stop` if we are not
signalled because of `force_sync`.
Fixes: http://tracker.ceph.com/issues/15695
Reported-by: Haomai Wang <haomaiwang@gmail.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
install-deps.sh: systemd-rpm-macros must be installed on SUSE
Reviewed-by: Abhishek Lekshmanan <abhishek.lekshmanan@gmail.com>
Reviewed-by: Loic Dachary <ldachary@redhat.com>
