1
0
mirror of https://github.com/samba-team/samba.git synced 2025-01-08 21:18:16 +03:00
samba-mirror/ctdb/tools/statd_callout_helper

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

259 lines
7.3 KiB
Plaintext
Raw Normal View History

#!/bin/sh
# statd must be configured to use statd_callout, CTDB's binary
# counterpart to this script, as its availability call-out.
#
# Modern NFS utils versions use /etc/nfs.conf:
#
# [statd]
# name = mycluster
ctdb-failover: Split statd_callout add-client/del-client rpc.statd is single-threaded and runs its HA callout synchronously. If it is too slow then latency accumulates and rpc.statd's backlog grows. Running a pair of add-client/del-client events with the current code averages ~0.030s in my test environment. This mean that 1000 clients reclaiming locks after failover can easily cause 10s of latency. This could cause rpc.statd to become unresponsive, resulting in a time out for an rpcinfo-based health check of the status service. Split the add-client/del-client events out to a standalone statd_callout executable, written in C, to be used as the HA callout for rpc.statd. All other functions move to statd_callout_helper. Now, running a pair of add-client/del-client events in my test environment averages only ~0.002s. This seems less likely to cause latency problems. The standalone statd_callout executable needs to read a configuration file, which is generated by statd_callout_helper from the "startup" event. It also needs access to a list of currently assigned public IPs. For backward compatibility, during installation a symlink is created from $CTDB_BASE/statd-callout to the new statd_callout, which is installed in the helper directory. Testing this as part of the eventscript unit tests starts to become even more of a hack than it used to be. However, the dependency on stubs and the corresponding setup of fake state makes it hard to move this elsewhere. Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Amitay Isaacs <amitay@gmail.com> Autobuild-User(master): Martin Schwenke <martins@samba.org> Autobuild-Date(master): Tue Jun 25 04:24:57 UTC 2024 on atb-devel-224
2024-05-10 04:42:26 +03:00
# ha-callout = /usr/local/libexec/ctdb/statd_callout
#
# Older Linux versions may use something like the following...
#
# /etc/sysconfig/nfs (Red Hat) or /etc/default/nfs-common (Debian):
# STATD_HOSTNAME="mycluster -H /usr/local/libexec/ctdb/statd_callout"
#
# If using Linux kernel NFS then the following should also be set in
# /etc/nfs.conf:
#
# [sm-notify]
# lift-grace = n
#
# See sm-notify(8) for details. This doesn't matter when using
# NFS-Ganesha because sm-notify's attempt to lift grace will fail
# silently if /proc/fs/lockd/nlm_end_grace is not found.
#
if [ -z "$CTDB_BASE" ]; then
ctdb-failover: Split statd_callout add-client/del-client rpc.statd is single-threaded and runs its HA callout synchronously. If it is too slow then latency accumulates and rpc.statd's backlog grows. Running a pair of add-client/del-client events with the current code averages ~0.030s in my test environment. This mean that 1000 clients reclaiming locks after failover can easily cause 10s of latency. This could cause rpc.statd to become unresponsive, resulting in a time out for an rpcinfo-based health check of the status service. Split the add-client/del-client events out to a standalone statd_callout executable, written in C, to be used as the HA callout for rpc.statd. All other functions move to statd_callout_helper. Now, running a pair of add-client/del-client events in my test environment averages only ~0.002s. This seems less likely to cause latency problems. The standalone statd_callout executable needs to read a configuration file, which is generated by statd_callout_helper from the "startup" event. It also needs access to a list of currently assigned public IPs. For backward compatibility, during installation a symlink is created from $CTDB_BASE/statd-callout to the new statd_callout, which is installed in the helper directory. Testing this as part of the eventscript unit tests starts to become even more of a hack than it used to be. However, the dependency on stubs and the corresponding setup of fake state makes it hard to move this elsewhere. Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Amitay Isaacs <amitay@gmail.com> Autobuild-User(master): Martin Schwenke <martins@samba.org> Autobuild-Date(master): Tue Jun 25 04:24:57 UTC 2024 on atb-devel-224
2024-05-10 04:42:26 +03:00
export CTDB_BASE="/usr/local/etc/ctdb"
fi
. "${CTDB_BASE}/functions"
# Overwrite this so we get some logging
die()
{
ctdb-failover: Split statd_callout add-client/del-client rpc.statd is single-threaded and runs its HA callout synchronously. If it is too slow then latency accumulates and rpc.statd's backlog grows. Running a pair of add-client/del-client events with the current code averages ~0.030s in my test environment. This mean that 1000 clients reclaiming locks after failover can easily cause 10s of latency. This could cause rpc.statd to become unresponsive, resulting in a time out for an rpcinfo-based health check of the status service. Split the add-client/del-client events out to a standalone statd_callout executable, written in C, to be used as the HA callout for rpc.statd. All other functions move to statd_callout_helper. Now, running a pair of add-client/del-client events in my test environment averages only ~0.002s. This seems less likely to cause latency problems. The standalone statd_callout executable needs to read a configuration file, which is generated by statd_callout_helper from the "startup" event. It also needs access to a list of currently assigned public IPs. For backward compatibility, during installation a symlink is created from $CTDB_BASE/statd-callout to the new statd_callout, which is installed in the helper directory. Testing this as part of the eventscript unit tests starts to become even more of a hack than it used to be. However, the dependency on stubs and the corresponding setup of fake state makes it hard to move this elsewhere. Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Amitay Isaacs <amitay@gmail.com> Autobuild-User(master): Martin Schwenke <martins@samba.org> Autobuild-Date(master): Tue Jun 25 04:24:57 UTC 2024 on atb-devel-224
2024-05-10 04:42:26 +03:00
script_log "statd_callout_helper" "$@"
exit 1
}
############################################################
60.nfs: we must always restart the lockmanager when the cluster has been reconfigured and ip addresses has changed. This is to make sure we get a clusterwide grace period for nfs locking. if we dont do this and only restart locking on the nodes that were direclty affected, a different client can take out a conflicting lock from a different node before affected clients has had a chance to reclaim all the locks lost during reconfigure. grace period on rhel5 kernel has bene increased to 90 seconds! statd-callout: we must restart lockmanager to ensure a clusterwide grace period for nfs. this makes locking "more correct" for nfs clients and prevents other clients/nodes from taking out a conflicting lock while a different client/node tries to reclaim lost locks. This makes it "almost consistent" for NFS clients but there is still the possibility that a cifs client can take out a conflicting lock before an nfs client has had a chance to reclaim an existing lock. This can not be solved with anything less than making the kernel nfs lock manager "samba aware" and making samba aware of the internal state of the kernel lock manager so that they can cooperate. we can not just stop/start the lockmanager back to back in rhel5 since if they are stopped/started too close to eachother then when the new lockmanager upon starting up sends out statd notifications two things can happen: 1, new lockmanager sends out notification BEFORE it has registered with portmapper leading to lockmanager starts lockmanager sends notification to the client client tries to recover the lock and tries to portmap the lockmanager port on the server. server is not (yet) registered with portmapper and server responds "no such program" to hte clients request to discover where lockmanager is. client then just completely gives up reclaiming the lock and doesnt even reattempt the portmapper call after some timeout. ==> lock reclaim failed. 2, if they are started back to back, and a client tries to reclaim the lock the lockmanager sometimes sends two responses back to back to the client. one with status NLM_GRANTED (==you got the lock reclaimed) and one with status NLM_DENIED (==you could not get the lock reclaimed) This confuses the client and leads to the server thinking that the client does have the lock and the client thinking it has not got the lock and orphaned locks result. We also send out additional notification messages of different formats to allow more legacy clients to interoperate with locking. (This used to be ctdb commit 13208c1aab2942e28dff87e38e6794bf0c026033)
2007-09-07 02:52:56 +04:00
ctdb_setup_state_dir "service" "nfs"
find_statd_sm_dir()
{
if [ -n "$CTDB_TEST_MODE" ]; then
_f="${CTDB_TEST_TMP_DIR}/sm"
mkdir -p "$_f" "${_f}.bak"
echo "$_f"
return
fi
for _sm_dir in /var/lib/nfs/statd/sm /var/lib/nfs/sm; do
if [ -d "$_sm_dir" ]; then
echo "$_sm_dir"
break
fi
done
}
# Ensure the state directory exists and can be written when called as
# a non-root user. Assume the user to run as is the owner of the
# system statd sm directory, since both rpc.statd and sm-notify run as
# this directory's owner, so it can read and modify the directory.
create_add_del_client_dir()
{
_dir="$1"
if [ ! -d "$_dir" ]; then
mkdir -p "$_dir" || die "Failed to create directory \"${_dir}\""
ref=$(find_statd_sm_dir)
[ -n "$ref" ] || die "Failed to find statd sm directory"
chown --reference="$ref" "$_dir"
fi
}
# script_state_dir set by ctdb_setup_state_dir()
# shellcheck disable=SC2154
ctdb-failover: Split statd_callout add-client/del-client rpc.statd is single-threaded and runs its HA callout synchronously. If it is too slow then latency accumulates and rpc.statd's backlog grows. Running a pair of add-client/del-client events with the current code averages ~0.030s in my test environment. This mean that 1000 clients reclaiming locks after failover can easily cause 10s of latency. This could cause rpc.statd to become unresponsive, resulting in a time out for an rpcinfo-based health check of the status service. Split the add-client/del-client events out to a standalone statd_callout executable, written in C, to be used as the HA callout for rpc.statd. All other functions move to statd_callout_helper. Now, running a pair of add-client/del-client events in my test environment averages only ~0.002s. This seems less likely to cause latency problems. The standalone statd_callout executable needs to read a configuration file, which is generated by statd_callout_helper from the "startup" event. It also needs access to a list of currently assigned public IPs. For backward compatibility, during installation a symlink is created from $CTDB_BASE/statd-callout to the new statd_callout, which is installed in the helper directory. Testing this as part of the eventscript unit tests starts to become even more of a hack than it used to be. However, the dependency on stubs and the corresponding setup of fake state makes it hard to move this elsewhere. Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Amitay Isaacs <amitay@gmail.com> Autobuild-User(master): Martin Schwenke <martins@samba.org> Autobuild-Date(master): Tue Jun 25 04:24:57 UTC 2024 on atb-devel-224
2024-05-10 04:42:26 +03:00
statd_callout_state_dir="${script_state_dir}/statd_callout"
statd_callout_db="ctdb.tdb"
statd_callout_queue_dir="${statd_callout_state_dir}/queue"
############################################################
# Read pairs of:
# server-IP client-IP
# from stdin and send associated SM_NOTIFY packets.
send_notifies()
{
# State must monotonically increase, across the entire
# cluster. Use seconds since epoch and assume the time is in
# sync across nodes. Even numbers mean service is shut down,
# odd numbers mean service is up. However, sm-notify always
# reads the state and converts it to odd (if necessary, by
# adding 1 when it is even) because it only sends "up"
# notifications. Note that there is a 2038 issue here but we
# will get to that later.
_state=$(date '+%s')
_helper="${CTDB_HELPER_BINDIR}/ctdb_smnotify_helper"
_notify_dir="${statd_callout_state_dir}/sm-notify"
mkdir -p "$_notify_dir"
while read -r _sip _cip; do
# Create a directory per server IP containing a file
# for each client IP
mkdir -p \
"${_notify_dir}/${_sip}/sm" \
"${_notify_dir}/${_sip}/sm.bak"
_out="${_notify_dir}/${_sip}/sm/${_cip}"
"$_helper" "monitor" "$_cip" "$_sip" >"$_out"
done
# Send notifications for server startup
_ref=$(find_statd_sm_dir)
for _sip_dir in "$_notify_dir"/*; do
if [ "$_sip_dir" = "${_notify_dir}/*" ]; then
break
fi
_sip="${_sip_dir##*/}" # basename
# Write the state as a host order 32-bit integer. See
# note at top of function about state.
_out="${_sip_dir}/state"
"$_helper" "state" "$_state" >"$_out"
# The ownership of the directory and contents should
# match the system's statd sm directory, so that
# sm-notify drops privileges and switches to run as
# the directory owner.
chown -R --reference="$_ref" "$_sip_dir"
timeout 10 sm-notify -d -f -m 0 -n -P "$_sip_dir" -v "$_sip"
rm -rf "$_sip_dir"
done
}
delete_records()
{
while read -r _sip _cip; do
_key="statd-state@${_sip}@${_cip}"
echo "\"${_key}\" \"\""
done | $CTDB ptrans "$statd_callout_db"
}
############################################################
# Keep a file per server-IP/client-IP pair, to keep track of the last
# "add-client" or "del-client'. These get pushed to a database during
# "update", which will generally be run once each "monitor" cycle. In
# this way we avoid scalability problems with flood of persistent
# transactions after a "notify" when all the clients re-take their
# locks.
startup()
{
create_add_del_client_dir "$statd_callout_queue_dir"
$CTDB attach "$statd_callout_db" persistent
ctdb-failover: Split statd_callout add-client/del-client rpc.statd is single-threaded and runs its HA callout synchronously. If it is too slow then latency accumulates and rpc.statd's backlog grows. Running a pair of add-client/del-client events with the current code averages ~0.030s in my test environment. This mean that 1000 clients reclaiming locks after failover can easily cause 10s of latency. This could cause rpc.statd to become unresponsive, resulting in a time out for an rpcinfo-based health check of the status service. Split the add-client/del-client events out to a standalone statd_callout executable, written in C, to be used as the HA callout for rpc.statd. All other functions move to statd_callout_helper. Now, running a pair of add-client/del-client events in my test environment averages only ~0.002s. This seems less likely to cause latency problems. The standalone statd_callout executable needs to read a configuration file, which is generated by statd_callout_helper from the "startup" event. It also needs access to a list of currently assigned public IPs. For backward compatibility, during installation a symlink is created from $CTDB_BASE/statd-callout to the new statd_callout, which is installed in the helper directory. Testing this as part of the eventscript unit tests starts to become even more of a hack than it used to be. However, the dependency on stubs and the corresponding setup of fake state makes it hard to move this elsewhere. Signed-off-by: Martin Schwenke <mschwenke@ddn.com> Reviewed-by: Amitay Isaacs <amitay@gmail.com> Autobuild-User(master): Martin Schwenke <martins@samba.org> Autobuild-Date(master): Tue Jun 25 04:24:57 UTC 2024 on atb-devel-224
2024-05-10 04:42:26 +03:00
_default="${CTDB_SCRIPT_VARDIR}/statd_callout.conf"
_config_file="${CTDB_STATD_CALLOUT_CONFIG_FILE:-"${_default}"}"
cat >"$_config_file" <<EOF
persistent_db
${statd_callout_queue_dir}
${CTDB_MY_PUBLIC_IPS_CACHE}
EOF
}
############################################################
case "$1" in
startup)
startup
;;
update)
cd "$statd_callout_queue_dir" ||
die "Failed to change directory to \"${statd_callout_queue_dir}\""
files=$(echo statd-state@*)
if [ "$files" = "statd-state@*" ]; then
# No files!
exit 0
fi
sed_expr=$(awk '{
ip = $1; gsub(/\./, "\\.", ip);
printf "/statd-state@%s@/p\n", ip }' "$CTDB_MY_PUBLIC_IPS_CACHE")
# Intentional multi-word expansion for multiple files
# shellcheck disable=SC2086
items=$(sed -n "$sed_expr" $files)
if [ -n "$items" ]; then
if echo "$items" | $CTDB ptrans "$statd_callout_db"; then
# shellcheck disable=SC2086
rm $files
fi
fi
;;
notify)
60.nfs: we must always restart the lockmanager when the cluster has been reconfigured and ip addresses has changed. This is to make sure we get a clusterwide grace period for nfs locking. if we dont do this and only restart locking on the nodes that were direclty affected, a different client can take out a conflicting lock from a different node before affected clients has had a chance to reclaim all the locks lost during reconfigure. grace period on rhel5 kernel has bene increased to 90 seconds! statd-callout: we must restart lockmanager to ensure a clusterwide grace period for nfs. this makes locking "more correct" for nfs clients and prevents other clients/nodes from taking out a conflicting lock while a different client/node tries to reclaim lost locks. This makes it "almost consistent" for NFS clients but there is still the possibility that a cifs client can take out a conflicting lock before an nfs client has had a chance to reclaim an existing lock. This can not be solved with anything less than making the kernel nfs lock manager "samba aware" and making samba aware of the internal state of the kernel lock manager so that they can cooperate. we can not just stop/start the lockmanager back to back in rhel5 since if they are stopped/started too close to eachother then when the new lockmanager upon starting up sends out statd notifications two things can happen: 1, new lockmanager sends out notification BEFORE it has registered with portmapper leading to lockmanager starts lockmanager sends notification to the client client tries to recover the lock and tries to portmap the lockmanager port on the server. server is not (yet) registered with portmapper and server responds "no such program" to hte clients request to discover where lockmanager is. client then just completely gives up reclaiming the lock and doesnt even reattempt the portmapper call after some timeout. ==> lock reclaim failed. 2, if they are started back to back, and a client tries to reclaim the lock the lockmanager sometimes sends two responses back to back to the client. one with status NLM_GRANTED (==you got the lock reclaimed) and one with status NLM_DENIED (==you could not get the lock reclaimed) This confuses the client and leads to the server thinking that the client does have the lock and the client thinking it has not got the lock and orphaned locks result. We also send out additional notification messages of different formats to allow more legacy clients to interoperate with locking. (This used to be ctdb commit 13208c1aab2942e28dff87e38e6794bf0c026033)
2007-09-07 02:52:56 +04:00
# we must restart the lockmanager (on all nodes) so that we get
# a clusterwide grace period (so other clients don't take out
60.nfs: we must always restart the lockmanager when the cluster has been reconfigured and ip addresses has changed. This is to make sure we get a clusterwide grace period for nfs locking. if we dont do this and only restart locking on the nodes that were direclty affected, a different client can take out a conflicting lock from a different node before affected clients has had a chance to reclaim all the locks lost during reconfigure. grace period on rhel5 kernel has bene increased to 90 seconds! statd-callout: we must restart lockmanager to ensure a clusterwide grace period for nfs. this makes locking "more correct" for nfs clients and prevents other clients/nodes from taking out a conflicting lock while a different client/node tries to reclaim lost locks. This makes it "almost consistent" for NFS clients but there is still the possibility that a cifs client can take out a conflicting lock before an nfs client has had a chance to reclaim an existing lock. This can not be solved with anything less than making the kernel nfs lock manager "samba aware" and making samba aware of the internal state of the kernel lock manager so that they can cooperate. we can not just stop/start the lockmanager back to back in rhel5 since if they are stopped/started too close to eachother then when the new lockmanager upon starting up sends out statd notifications two things can happen: 1, new lockmanager sends out notification BEFORE it has registered with portmapper leading to lockmanager starts lockmanager sends notification to the client client tries to recover the lock and tries to portmap the lockmanager port on the server. server is not (yet) registered with portmapper and server responds "no such program" to hte clients request to discover where lockmanager is. client then just completely gives up reclaiming the lock and doesnt even reattempt the portmapper call after some timeout. ==> lock reclaim failed. 2, if they are started back to back, and a client tries to reclaim the lock the lockmanager sometimes sends two responses back to back to the client. one with status NLM_GRANTED (==you got the lock reclaimed) and one with status NLM_DENIED (==you could not get the lock reclaimed) This confuses the client and leads to the server thinking that the client does have the lock and the client thinking it has not got the lock and orphaned locks result. We also send out additional notification messages of different formats to allow more legacy clients to interoperate with locking. (This used to be ctdb commit 13208c1aab2942e28dff87e38e6794bf0c026033)
2007-09-07 02:52:56 +04:00
# conflicting locks through other nodes before all locks have been
# reclaimed)
# we need these settings to make sure that no tcp connections survive
# across a very fast failover/failback
#echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout
#echo 0 > /proc/sys/net/ipv4/tcp_max_tw_buckets
#echo 0 > /proc/sys/net/ipv4/tcp_max_orphans
60.nfs: we must always restart the lockmanager when the cluster has been reconfigured and ip addresses has changed. This is to make sure we get a clusterwide grace period for nfs locking. if we dont do this and only restart locking on the nodes that were direclty affected, a different client can take out a conflicting lock from a different node before affected clients has had a chance to reclaim all the locks lost during reconfigure. grace period on rhel5 kernel has bene increased to 90 seconds! statd-callout: we must restart lockmanager to ensure a clusterwide grace period for nfs. this makes locking "more correct" for nfs clients and prevents other clients/nodes from taking out a conflicting lock while a different client/node tries to reclaim lost locks. This makes it "almost consistent" for NFS clients but there is still the possibility that a cifs client can take out a conflicting lock before an nfs client has had a chance to reclaim an existing lock. This can not be solved with anything less than making the kernel nfs lock manager "samba aware" and making samba aware of the internal state of the kernel lock manager so that they can cooperate. we can not just stop/start the lockmanager back to back in rhel5 since if they are stopped/started too close to eachother then when the new lockmanager upon starting up sends out statd notifications two things can happen: 1, new lockmanager sends out notification BEFORE it has registered with portmapper leading to lockmanager starts lockmanager sends notification to the client client tries to recover the lock and tries to portmap the lockmanager port on the server. server is not (yet) registered with portmapper and server responds "no such program" to hte clients request to discover where lockmanager is. client then just completely gives up reclaiming the lock and doesnt even reattempt the portmapper call after some timeout. ==> lock reclaim failed. 2, if they are started back to back, and a client tries to reclaim the lock the lockmanager sometimes sends two responses back to back to the client. one with status NLM_GRANTED (==you got the lock reclaimed) and one with status NLM_DENIED (==you could not get the lock reclaimed) This confuses the client and leads to the server thinking that the client does have the lock and the client thinking it has not got the lock and orphaned locks result. We also send out additional notification messages of different formats to allow more legacy clients to interoperate with locking. (This used to be ctdb commit 13208c1aab2942e28dff87e38e6794bf0c026033)
2007-09-07 02:52:56 +04:00
# Delete the notification list for statd, we don't want it to
# ping any clients
dir=$(find_statd_sm_dir)
rm -f "${dir}/"* "${dir}.bak/"*
# We must also let some time pass between stopping and
# restarting the lock manager. Otherwise there is a window
# where the lock manager will respond "strangely" immediately
# after restarting it, which causes clients to fail to reclaim
# their locks.
nfs_callout_init
"$CTDB_NFS_CALLOUT" "stop" "nlockmgr" >/dev/null 2>&1
sleep 2
"$CTDB_NFS_CALLOUT" "start" "nlockmgr" >/dev/null 2>&1
60.nfs: we must always restart the lockmanager when the cluster has been reconfigured and ip addresses has changed. This is to make sure we get a clusterwide grace period for nfs locking. if we dont do this and only restart locking on the nodes that were direclty affected, a different client can take out a conflicting lock from a different node before affected clients has had a chance to reclaim all the locks lost during reconfigure. grace period on rhel5 kernel has bene increased to 90 seconds! statd-callout: we must restart lockmanager to ensure a clusterwide grace period for nfs. this makes locking "more correct" for nfs clients and prevents other clients/nodes from taking out a conflicting lock while a different client/node tries to reclaim lost locks. This makes it "almost consistent" for NFS clients but there is still the possibility that a cifs client can take out a conflicting lock before an nfs client has had a chance to reclaim an existing lock. This can not be solved with anything less than making the kernel nfs lock manager "samba aware" and making samba aware of the internal state of the kernel lock manager so that they can cooperate. we can not just stop/start the lockmanager back to back in rhel5 since if they are stopped/started too close to eachother then when the new lockmanager upon starting up sends out statd notifications two things can happen: 1, new lockmanager sends out notification BEFORE it has registered with portmapper leading to lockmanager starts lockmanager sends notification to the client client tries to recover the lock and tries to portmap the lockmanager port on the server. server is not (yet) registered with portmapper and server responds "no such program" to hte clients request to discover where lockmanager is. client then just completely gives up reclaiming the lock and doesnt even reattempt the portmapper call after some timeout. ==> lock reclaim failed. 2, if they are started back to back, and a client tries to reclaim the lock the lockmanager sometimes sends two responses back to back to the client. one with status NLM_GRANTED (==you got the lock reclaimed) and one with status NLM_DENIED (==you could not get the lock reclaimed) This confuses the client and leads to the server thinking that the client does have the lock and the client thinking it has not got the lock and orphaned locks result. We also send out additional notification messages of different formats to allow more legacy clients to interoperate with locking. (This used to be ctdb commit 13208c1aab2942e28dff87e38e6794bf0c026033)
2007-09-07 02:52:56 +04:00
# Construct a sed expression to take catdb output and produce pairs of:
# server-IP client-IP
# but only for the server-IPs that are hosted on this node.
sed_expr=$(awk '{
ip = $1; gsub(/\./, "\\.", ip);
printf "s/^key.*=.*statd-state@\\(%s\\)@\\([^\"]*\\).*/\\1 \\2/p\n", ip }' \
"$CTDB_MY_PUBLIC_IPS_CACHE")
statd_state=$($CTDB catdb "$statd_callout_db" |
sed -n "$sed_expr" |
sort)
[ -n "$statd_state" ] || exit 0
echo "$statd_state" | send_notifies
echo "$statd_state" | delete_records
# Remove any stale touch files (i.e. for IPs not currently
# hosted on this node and created since the last "update").
# There's nothing else we can do with them at this stage.
pnn=$(ctdb_get_pnn)
$CTDB ip all |
tail -n +2 |
awk -v pnn="$pnn" 'pnn != $2 { print $1 }' |
while read -r sip; do
rm -f "${statd_callout_queue_dir}/statd-state@${sip}@"*
done
;;
esac