3 # this script needs to be installed so that statd points to it with the -H
4 # command line argument. The easiest way to do that is to put something like this in
6 # STATD_HOSTNAME="myhostname -H /etc/ctdb/statd-callout"
8 [ -z "$CTDB_BASE" ] && {
9 export CTDB_BASE="/etc/ctdb"
12 . $CTDB_BASE/functions
16 [ -z "$STATD_SHARED_DIRECTORY" ] && {
17 echo STATD_SHARED_DIRECTORY not configured. statd-callout failed.
21 [ -d $STATD_SHARED_DIRECTORY ] || exit 0
23 [ -z $NFS_HOSTNAME ] && {
24 echo NFS_HOSTNAME is not configured. statd-callout failed.
30 # the callout does not tell us to which ip the client connected
31 # so we must add it to all the ips that we serve
32 for f in $CTDB_BASE/state/statd/ip/*; do
34 [ -d $STATD_SHARED_DIRECTORY/$ip ] || /bin/mkdir $STATD_SHARED_DIRECTORY/$ip
35 touch $STATD_SHARED_DIRECTORY/$ip/$2
39 # the callout does not tell us to which ip the client connected
40 # so we must add it to all the ips that we serve
41 for f in $CTDB_BASE/state/statd/ip/*; do
43 /bin/rm -f $STATD_SHARED_DIRECTORY/$ip/$2
47 # we must restart the lockmanager (on all nodes) so that we get
48 # a clusterwide grace period (so other clients dont take out
49 # conflicting locks through other nodes before all locks have been
52 # we need these settings to make sure that no tcp connections survive
53 # across a very fast failover/failback
54 #echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout
55 #echo 0 > /proc/sys/net/ipv4/tcp_max_tw_buckets
56 #echo 0 > /proc/sys/net/ipv4/tcp_max_orphans
58 # rebuild the state directory for the local statd to use the correct
59 # state value and to initally send notifications to all clients
60 rm -f /var/lib/nfs/statd/sm/*
61 rm -f /var/lib/nfs/statd/sm.bak/*
62 cat $STATD_SHARED_DIRECTORY/state >/var/lib/nfs/statd/state
65 # we must keep a monotonically increasing state variable for the entire
66 # cluster so state always increases when ip addresses fail from one
68 [ ! -f $STATD_SHARED_DIRECTORY/state ] && {
69 echo 1 | awk '{printf("%c%c%c%c", $0, $0/256, $0/256/256, $0/256/256/256);}' >$STATD_SHARED_DIRECTORY/state
72 STATE=`od -t d4 $STATD_SHARED_DIRECTORY/state | head -1 | sed -e "s/^[0-9]*[^0-9]*//"`
73 # write current state+2 back to the state file
74 # the /2 *2 are to ensure that state is odd. state must be odd.
75 STATE=`expr $STATE "/" 2 "*" 2 "+" 3`
76 echo $STATE | awk '{printf("%c%c%c%c", $0, $0/256, $0/256/256, $0/256/256/256);}' >$STATD_SHARED_DIRECTORY/state
80 # we must also let some time pass between stopping and restarting the
81 # lockmanager since othervise there is a window where the lockmanager
82 # will respond "strangely" immediately after restarting it, which
83 # causes clients to fail to reclaim the locks.
85 startstop_nfslock stop > /dev/null 2>&1
88 # copy all monitored clients on this node to the local lockmanager
89 for f in `/bin/ls $CTDB_BASE/state/statd/ip/* 2>/dev/null`; do
91 [ -d $STATD_SHARED_DIRECTORY/$ip ] && [ -x /usr/bin/smnotify ] && {
92 for g in `/bin/ls $STATD_SHARED_DIRECTORY/$ip/* 2>/dev/null`; do
94 touch /var/lib/nfs/statd/sm/$client
99 # now start lockmanager again with the new state directory.
100 startstop_nfslock start > /dev/null 2>&1
102 # we now need to send out additional statd notifications to ensure
103 # that clients understand that the lockmanager has restarted.
104 # we have three cases:
105 # 1, clients that ignore the ip address the stat notification came from
106 # and ONLY care about the 'name' in the notify packet.
107 # these clients ONLY work with lock failover IFF that name
108 # can be resolved into an ipaddress that matches the one used
109 # to mount the share. (==linux clients)
110 # This is handled when starting lockmanager above, but those
111 # packets are sent from the "wrong" ip address, something linux
112 # clients are ok with, buth other clients will barf at.
113 # 2, Some clients only accept statd packets IFF they come from the
114 # 'correct' ip address.
115 # 2a,Send out the notification using the 'correct' ip address and also
116 # specify the 'correct' hostname in the statd packet.
117 # Some clients require both the correct source address and also the
118 # correct name. (these clients also ONLY work if the ip addresses
119 # used to map the share can be resolved into the name returned in
120 # the notify packet.)
121 # 2b,Other clients require that the source ip address of the notify
122 # packet matches the ip address used to take out the lock.
123 # I.e. that the correct source address is used.
124 # These clients also require that the statd notify packet contains
125 # the name as the ip address used when the lock was taken out.
127 # Both 2a and 2b are commonly used in lockmanagers since they maximize
128 # probability that the client will accept the statd notify packet and
129 # not just ignore it.
130 for f in `/bin/ls $CTDB_BASE/state/statd/ip/* 2>/dev/null`; do
132 [ -d $STATD_SHARED_DIRECTORY/$ip ] && [ -x /usr/bin/smnotify ] && {
133 for g in `/bin/ls $STATD_SHARED_DIRECTORY/$ip/* 2>/dev/null`; do
136 # send out notifications from the "correct" address
137 # (the same addresse as where the lock was taken out
138 # on) some clients require that the source address
139 # matches where the lock was taken out.
140 # also send it both as a name that the client
141 # hopefully can resolve into the server ip and
142 # and also by specifying the raw ip address as name.
143 /usr/bin/smnotify --client=$client --ip=$ip --server=$ip --stateval=$STATE
144 /usr/bin/smnotify --client=$client --ip=$ip --server=$NFS_HOSTNAME --stateval=$STATE