If we've closed the session we shouldn't waste our time on this op.
Fixes: #13262 (we should not add a subscription to a disconnected session)
Signed-off-by: Sage Weil <sage@redhat.com>
Unconditionally attach a Session, so that when we push an op back through
dispatch_op it isn't in a weird broken state.
Move the waitinglist check to the bottom. Use s->global_id == 0 to tell
whether a client has authenticated, and zap sessions based on that.
Signed-off-by: Sage Weil <sage@redhat.com>
In the case where a client dies, and another client immediately
tries to access a file locked by the dead client, we would
previously *sometimes* emit a "client.xyz isn't responding to
mclientcaps" warning to the cluster log, right before
evicting the stale session. This was because the timeout
for the session eviction and the timeout for the
warning message are both 60s.
Fix this by checking the stale sessions before doing the
warning message check in Locker. If a session is going
to get evicted in this tick, it will already be gone
by the time Locker thinks about emitting the warning
message.
Fixes: #13334
Signed-off-by: John Spray <john.spray@redhat.com>
Do not attempt to create a user if it is root because it already exists.
http://tracker.ceph.com/issues/13355Fixes: #13355
Signed-off-by: Loic Dachary <ldachary@redhat.com>
* handle the case where a single pull request is associated with
multiple pull requests
* encapsulate the quest for the original in a function for easier
maintenance
* add the --verbose flag for debugging
Signed-off-by: Loic Dachary <ldachary@redhat.com>
There is no need to restart the daemons when removing ceph-selinux
package if SELinux is not enabled.
Fixes: #13061
Signed-off-by: Boris Ranto <branto@redhat.com>
This patch minimizes the amount of daemon stop/start procedures when
upgrading ceph-selinux package. With this patch, the daemons get
restarted only if SELinux is enabled and the SELinux policy version
changed in the meantime.
Fixes: #13061
Signed-off-by: Boris Ranto <branto@redhat.com>
Otherwise, we could erroneously promote a snap after not promoting
the missing head for which we have a cached obc and ssc.
Fixes: #13323
Signed-off-by: Samuel Just <sjust@redhat.com>
Allow librados users to opt to receive ENOSPC or EDQUOT when they submit
an operation against a full cluster. This should only be used if the
librados app can handle those errors gracefully (librbd, for example,
cannot).
Also note that this allows savvy librados users to send delete operations;
they will get either a success or EDQUOT, depending on whether the
operation results in a net drop in space utilization.
Signed-off-by: Sage Weil <sage@redhat.com>
We may send a notify to the cluster multiple times due to OSDMap
changes. In some cases, earlier notify attempts may complete with
an error, while later attempts succeed. We need to only pay
attention to the most-recently send notify's completion.
Do this by making note of the notify_id in the initial ACK (only
present when talking to newer OSDs). When we get a notify
completion, match it against our expected notify_id (if we have
one) or else discard it.
This is important because in some cases an early notify completion
may be an error while a later one succeeds.
Note that if we are talking to an old cluster we will simply not record a
notify_id and our behavior will be the same as before (we will trust any
notify completion we get).
Fixes: #13114
Signed-off-by: Sage Weil <sage@redhat.com>
The OSD assigns a unique ID to each notify it queues for
processing. Include this in the reply to the notifier so that
they can match it up with the eventual completions they receive.
This is necessary to distinguish between multiple completions
they may receive if there is PG peering and the notify is resent.
In particular, an earlier notify may return an error when a later
attempt succeeds.
This is forwards and backwards compatible: new clients will make use of
this reply payload but older clients ignore it.
Signed-off-by: Sage Weil <sage@redhat.com>
The check is a no-op. We already verify the uid/gid combo is valid and
that the dir is writeable with MAY_WRITE. The new file is always set to
the caller uid:gid.
Signed-off-by: Sage Weil <sage@redhat.com>
