Puh, i haven´t thought the discussion became this direction.
Corosync is not the only software, which need shared memory, so it is part of the OS startup to provide it, not part of Corosync or Pacemaker.
And yes, it is too late to mount it in Pacemaker startup.
Even in most embedded Linux installations share memory is available, just with smaller size.
So, there is no need to include anything in Corosync or Pacemaker startup directly.
My answer about shared memory is valid and neccessary only for anaconda based installations.
When you install a RedHat system, the installation process is done by anaconda with a running miniroot (install.img) as ram disk.
Within this miniroot shared memory is enabled, but they (RedHat) missed the mount.
If somebody wants to correct it, RedHat (more specific the maintainer of install.img) is the correct address for this gap.
To have world read access to CRM_CORE_DIR should be enough in case a core pattern set explicit to another directory (not tested yet).
When calling resource agents, CRM_CORE_DIR is the current PWD (tested with echo all environment variables to a file inside monitor call).
If this directory is not readable during switch user inside resource agent, stupid things could happen. Anyhow, it is not a good method of writing resource agents, switching user without setting the environment of the switched user. So, this is no fault of Pacemaker, more of loose programmed resource agents.
When the resource agent or any of its childs produces a core dump, it goes either to the current directory or to the directory specified with kernel core pattern.
If the core will go into the current directory and it is written by a switched user, who is not member of pcmk_gid, the core get lost.
As i am not sure every resource agent is written with proper switch user environment and not rewriting my core pattern, enable world write on CRM_CCORE_DIR was the easy work around for it.
Rainer
Gesendet: Freitag, 29. März 2013 um 09:51 Uhr
Von: "Jacek Konieczny" <jaj...@jajcus.net>
An: pacemaker@oss.clusterlabs.org
Betreff: Re: [Pacemaker] issues when installing on pxe booted environment
Von: "Jacek Konieczny" <jaj...@jajcus.net>
An: pacemaker@oss.clusterlabs.org
Betreff: Re: [Pacemaker] issues when installing on pxe booted environment
On Fri, 29 Mar 2013 11:37:37 +1100
Andrew Beekhof <and...@beekhof.net> wrote:
> On Thu, Mar 28, 2013 at 10:43 PM, Rainer Brestan
> <rainer.bres...@gmx.net> wrote:
> > Hi John,
> > to get Corosync/Pacemaker running during anaconda installation, i
> > have created a configuration RPM package which does a few actions
> > before starting Corosync and Pacemaker.
> >
> > An excerpt of the post install of this RPM.
> > # mount /dev/shm if not already existing, otherwise openais cannot
> > work if [ ! -d /dev/shm ]; then
> > mkdir /dev/shm
> > mount /dev/shm
> > fi
>
> Perhaps mention this to the corosync guys, it should probably go into
> their init script.
I don't think so. It is just a part of modern Linux system environment.
corosync is not supposed to mount the root filesystem or /proc –
mounting /dev/shm is not its responsibility either.
BTW The excerpt above assumes there is a /dev/shm entry in /etc/fstab.
Should this be added there by the corosync init script too?
Greets,
Jacek
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
Andrew Beekhof <and...@beekhof.net> wrote:
> On Thu, Mar 28, 2013 at 10:43 PM, Rainer Brestan
> <rainer.bres...@gmx.net> wrote:
> > Hi John,
> > to get Corosync/Pacemaker running during anaconda installation, i
> > have created a configuration RPM package which does a few actions
> > before starting Corosync and Pacemaker.
> >
> > An excerpt of the post install of this RPM.
> > # mount /dev/shm if not already existing, otherwise openais cannot
> > work if [ ! -d /dev/shm ]; then
> > mkdir /dev/shm
> > mount /dev/shm
> > fi
>
> Perhaps mention this to the corosync guys, it should probably go into
> their init script.
I don't think so. It is just a part of modern Linux system environment.
corosync is not supposed to mount the root filesystem or /proc –
mounting /dev/shm is not its responsibility either.
BTW The excerpt above assumes there is a /dev/shm entry in /etc/fstab.
Should this be added there by the corosync init script too?
Greets,
Jacek
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
