[ClusterLabs] Upgrade corosync problem
jpokorny at redhat.com
Fri Jun 29 11:46:13 EDT 2018
On 26/06/18 11:03 +0200, Salvatore D'angelo wrote:
> Yes, sorry you’re right I could find it by myself.
> However, I did the following:
> 1. Added the line you suggested to /etc/fstab
> 2. mount -o remount /dev/shm
> 3. Now I correctly see /dev/shm of 512M with df -h
> Filesystem Size Used Avail Use% Mounted on
> overlay 63G 11G 49G 19% /
> tmpfs 64M 4.0K 64M 1% /dev
> tmpfs 1000M 0 1000M 0% /sys/fs/cgroup
> osxfs 466G 158G 305G 35% /Users
> /dev/sda1 63G 11G 49G 19% /etc/hosts
> shm 512M 15M 498M 3% /dev/shm
> tmpfs 1000M 0 1000M 0% /sys/firmware
> tmpfs 128M 0 128M 0% /tmp
> The errors in log went away. Consider that I remove the log file
> before start corosync so it does not contains lines of previous
> But the command:
> corosync-quorumtool -ps
> still give:
> Cannot initialize QUORUM service
> Consider that few minutes before it gave me the message:
> Cannot initialize CFG service
> I do not know the differences between CFG and QUORUM in this case.
> If I try to start pacemaker the service is OK but I see only
> pacemaker and the Transport does not work if I try to run a cam
> Any suggestion?
Frankly, best generic suggestion I can serve with is to learn
sufficient portions of the details about the tool you are relying on.
I had a second look and it seems that what drives the actual
size of the container's /dev/shm mountpoint with docker
(per other response, you don't seem to be using --ipc switch) is
it's --shm-size option for "run" subcommand (hence it's rather
a property of the run-time, as the default of "64m" may be
silently overriding your believed-to-be-persistent static changes
within the container).
Try using that option and you'll see. Definitely keep you mind open
regarding "container != magic-less system" inequality.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Users