Hi.
I'm running CentOS 6.4 with resource-agents-3.9.2-21.el6_4.3.x86_64
I've noticed a problem that resource agents don't create pid directories
correctly.
Let's take samba for example. So, samba resource agent in start()
function calls function 'create_pid_directory', whose body is in file:
/usr/share/cluster/utils/config-utils.sh
and relevant lines looks like this:
declare RA_COMMON_pid_dir=/var/run/cluster
create_pid_directory()
{
declare program_name="$(basename $0 | sed 's/^\(.*\)\..*/\1/')"
declare dirname="$RA_COMMON_pid_dir/$program_name"
if [ -d "$dirname" ]; then
return 0;
fi
chmod 711 "$RA_COMMON_pid_dir"
mkdir -p "$dirname"
return 0;
}
So, if a samba.sh resource agent calls create_pid_directory(), dirname
variable will have the value of '/var/run/cluster/samba', thus, that
directory will be created.
BUT, samba.sh resource agent also has the following line:
declare SAMBA_pid_dir="`generate_name_for_pid_dir`"
Looking at generate_name_for_pid_dir() function, it's obvious that the
value of SAMBA_pid_dir is '/var/run/cluster/samba/samba:${name}'.
For this snippet of cluster.conf:
<service name="myservice">
<ip ref="192.168.10.10"/>
<samba ref="ha_smb"/>
</service>
SAMBA_pid_dir is /var/run/cluster/samba/samba:ha_smb
That means that service won't be able to put pid file in that directory
because directory does not exit... create_pid_directory() creates only
the parent directory, so the user has to create it manually.
I think this is a huge bug, but am really mystified how did it survive
for so long? The solution is pretty straightforward and simple:
--- /usr/share/cluster/utils/config-utils.sh.orig 2013-09-08
04:48:47.000000000 +0200
+++ /usr/share/cluster/utils/config-utils.sh 2013-09-08
04:49:02.000000000 +0200
@@ -230,7 +230,7 @@
fi
chmod 711 "$RA_COMMON_pid_dir"
- mkdir -p "$dirname"
+ mkdir -p "$dirname/$OCF_RESOURCE_INSTANCE"
if [ "$program_name" = "mysql" ]; then
chown mysql.root "$dirname"
Should I file a bug report ?!
--
Jakov Sosic
www.srce.unizg.hr
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster