[Linux-ha-dev] [PATCH] support LSBs /run directory

[Timur I. Bakeyev]

Hi, all!

Recent Debian(and Ubuntu?) started to use tmpfs based /run directory for
the PID files, some of the RA scripts fail to check/store PID files, if
they been kept in subdirectories of the {/var}/run directory.

By first glance I could spot at least at least named, zabbixserver, mysql,
mysql-proxy and lxc scripts, which store their PIDs in such
subdirectories. Also,
apache2 may have to deal with that, I'm not sure.

I've raised an issue:

https://github.com/ClusterLabs/resource-agents/issues/351

Maybe corresponding maintainers/interested developers could take a look
onto that.

As of myself I've experienced failure of the RA named in the Debian wheezy
environment, so had to patch RA named accordingly:

https://github.com/ClusterLabs/resource-agents/issues/350

Serge, please have a look and comment/commit if appropriate :)

With best regards,
Timur Bakeyev.

[Timur I. Bakeyev]

Hi, guys!

Any reaction, please?

Post by Timur I. Bakeyev
Hi, all!
Recent Debian(and Ubuntu?) started to use tmpfs based /run directory for
the PID files, some of the RA scripts fail to check/store PID files, if
they been kept in subdirectories of the {/var}/run directory.
By first glance I could spot at least at least named, zabbixserver,
mysql, mysql-proxy and lxc scripts, which store their PIDs in such
subdirectories. Also, apache2 may have to deal with that, I'm not sure.
https://github.com/ClusterLabs/resource-agents/issues/351
Maybe corresponding maintainers/interested developers could take a look
onto that.
As of myself I've experienced failure of the RA named in the Debian wheezy
https://github.com/ClusterLabs/resource-agents/issues/350
Serge, please have a look and comment/commit if appropriate :)
With best regards,
Timur Bakeyev.

[Lars Ellenberg]

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
local $varrun=@@__varrun_or_whatever_autofoo_calls_it__@@
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1

# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}


Then use that early in the various resource agents,
maybe where the defaults are defined.

Yes?

Lars Ellenberg

Post by Timur I. Bakeyev

Post by Timur I. Bakeyev
Hi, all!
Recent Debian(and Ubuntu?) started to use tmpfs based /run directory for
the PID files, some of the RA scripts fail to check/store PID files, if
they been kept in subdirectories of the {/var}/run directory.
By first glance I could spot at least at least named, zabbixserver,
mysql, mysql-proxy and lxc scripts, which store their PIDs in such
subdirectories. Also, apache2 may have to deal with that, I'm not sure.
https://github.com/ClusterLabs/resource-agents/issues/351
Maybe corresponding maintainers/interested developers could take a look
onto that.
As of myself I've experienced failure of the RA named in the Debian wheezy
https://github.com/ClusterLabs/resource-agents/issues/350
Serge, please have a look and comment/commit if appropriate :)
With best regards,
Timur Bakeyev.

[Timur I. Bakeyev]

Hi, Lars!

On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg

Post by Lars Ellenberg

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1
# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}
Then use that early in the various resource agents,
maybe where the defaults are defined.
Yes?

That would be even better! There are few more RAs that would benefit from
that.

I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd put
some meaningful defaults for the later two parameters:

local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}

Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.

need a bit more magic, smth. like:

if [ -n "${path##$varrun}" ]

or alike.

With best regards,
Timur.

[Serge Dubrouski]

Lars -

I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if it
doesn't present? The goal is to cover the case when /run , or any other
directory, is used instead of /var/run

Post by Timur I. Bakeyev
Hi, Lars!

Post by Lars Ellenberg

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1
# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}
Then use that early in the various resource agents,
maybe where the defaults are defined.
Yes?

That would be even better! There are few more RAs that would benefit from
that.
I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd put
local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}
Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.
if [ -n "${path##$varrun}" ]
or alike.
With best regards,
Timur.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[Lars Ellenberg]

Post by Serge Dubrouski
Lars -
I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if it
doesn't present? The goal is to cover the case when /run , or any other
directory, is used instead of /var/run

Intention was to not hardcode paths in the resource agents,
when those paths may depend on build-time configuration of the software
they are supposed to control.

You'd only do "require_run_dir httpd",
and that would create /var/run/httpd, /run/httpd/,
/usr/local/whatever-I-told-autofoo-at-build-time/httpd
appropriately.

But in case the prefix is already there, do not double the prefix.

This is to avoid distribution (version) specific resource agents,
or the transition of all resource agents to "*.in".

If that makes sense.

Lars

Post by Serge Dubrouski

Post by Timur I. Bakeyev
Hi, Lars!

Post by Lars Ellenberg

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1
# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}
Then use that early in the various resource agents,
maybe where the defaults are defined.
Yes?

That would be even better! There are few more RAs that would benefit from
that.
I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd put
local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}
Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.
if [ -n "${path##$varrun}" ]
or alike.
With best regards,
Timur.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

--
Serge Dubrouski.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[Timur I. Bakeyev]

Hi, Lars!

On Fri, Dec 20, 2013 at 10:25 AM, Lars Ellenberg

Post by Lars Ellenberg

Post by Serge Dubrouski
Lars -
I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if

it

Post by Serge Dubrouski
doesn't present? The goal is to cover the case when /run , or any other
directory, is used instead of /var/run

Intention was to not hardcode paths in the resource agents,
when those paths may depend on build-time configuration of the software
they are supposed to control.
You'd only do "require_run_dir httpd",
and that would create /var/run/httpd, /run/httpd/,
/usr/local/whatever-I-told-autofoo-at-build-time/httpd
appropriately.
But in case the prefix is already there, do not double the prefix.
This is to avoid distribution (version) specific resource agents,
or the transition of all resource agents to "*.in".
If that makes sense.

It does make a lot of sense. I just think that case switch wouldn't do what
is intended. Can you comment my previous mail?

With regards,
Timur Bakeyev.

Post by Lars Ellenberg

Post by Serge Dubrouski

Post by Timur I. Bakeyev
Hi, Lars!
On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <

Post by Lars Ellenberg

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1
# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}
Then use that early in the various resource agents,
maybe where the defaults are defined.
Yes?

That would be even better! There are few more RAs that would benefit

from

Post by Serge Dubrouski

Post by Timur I. Bakeyev
that.
I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd

put

Post by Serge Dubrouski

Post by Timur I. Bakeyev
local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}
Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.
if [ -n "${path##$varrun}" ]
or alike.
With best regards,
Timur.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

--
Serge Dubrouski.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[Timur I. Bakeyev]

Post by Serge Dubrouski
Lars -
I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if
it doesn't present? The goal is to cover the case when /run , or any other
directory, is used instead of /var/run

/run is used instead of /var/run, and /var/run is a symlink to /run. Within
a distribution RUNDIR is, kind of, hardcoded, no matter what is it.

So real question is to distinct usage of the plain RUNDIR and sub-directory
under it, as later one requires some special handling on memory based file
systems.


With regards,
Timur Bakeyev.

Post by Serge Dubrouski

Post by Timur I. Bakeyev
Hi, Lars!
On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <

Post by Lars Ellenberg

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1
# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}
Then use that early in the various resource agents,
maybe where the defaults are defined.
Yes?

That would be even better! There are few more RAs that would benefit from
that.
I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd put
local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}
Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.
if [ -n "${path##$varrun}" ]
or alike.
With best regards,
Timur.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

--
Serge Dubrouski.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[Lars Ellenberg]

Post by Timur I. Bakeyev

Post by Serge Dubrouski
Lars -
I'm a bit lost on "path=$varrun/$path". Why do we need to add $varrun if
it doesn't present? The goal is to cover the case when /run , or any other
directory, is used instead of /var/run

Ignore for a moment that I used the variable name "varrun".

Post by Timur I. Bakeyev
/run is used instead of /var/run, and /var/run is a symlink to /run. Within
a distribution RUNDIR is, kind of, hardcoded, no matter what is it.

That's why I used the @@__autofoo_notation__@@ and I'm too lazy to look
up what the correct name between @@ @@ would be; last time I checked,
people where still discussing --rundir, --varrundir, --runstatedir and
others.

Anyways, that's supposed to be the "distribution wide hardcoded default",
and that would be replaced by autofoo/configure at build time of this
package.

I think we have it already in ocf-directories.in as
: ${HA_VARRUN:=@localstatedir@/run/}
and we probably should change that to
: ${HA_RUNSTATEDIR:=@runstatedir@}
(or HA_RUNDIR:=@rundir@; whatever will be the proper autofoo name for it)
and keep the alias
HA_VARRUN=$HA_RUNSTATEDIR

And now, assume that this variable, despite the name,
has a value of /run on those distributions that use /run,
and /var/run on those that use that,
and $home/var/run or $prefix/var/run when people install locally
(not that that'd make much sense for resoruce-agents...)


Ok?

Post by Timur I. Bakeyev
So real question is to distinct usage of the plain RUNDIR and sub-directory
under it, as later one requires some special handling on memory based file
systems.
With regards,
Timur Bakeyev.

Post by Serge Dubrouski

Post by Timur I. Bakeyev
Hi, Lars!
On Tue, Dec 17, 2013 at 1:43 PM, Lars Ellenberg <

Post by Lars Ellenberg

Post by Timur I. Bakeyev
Hi, guys!
Any reaction, please?

Probably best to add a helper to ocf-functions, say,
# require_run_dir <mode> user:group path
require_run_dir()
{
local mode=$1 owner=$2 path=$3
case $path in
$varrun/*) : nothing ;;
*)
path=$varrun/$path ;;
esac
test -d $path && return 0
[ $(id -u) = 0 ] || return 1
# (or some helper function mkdir_p, in case we doubt -p is available...)
mkdir -p $path && chown $owner $path && chmod $mode $path
}
Then use that early in the various resource agents,
maybe where the defaults are defined.
Yes?

That would be even better! There are few more RAs that would benefit from
that.
I'd only invert the parameters, as path is mandatory, permissions are
semi-optional and owner, as in 99% we run as root - optional. And I'd put
local path=$1 mode=$2 owner=$3
: ${mode:=0755}
: ${owner:=root}
Also, as 'path' is usually is smth. like '/var/run/named' or
'/var/run/zabbix' I'm afraid that switch will do nothing in any case.
if [ -n "${path##$varrun}" ]
or alike.
With best regards,
Timur.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

--
Serge Dubrouski.
_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

_______________________________________________________
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/