[ClusterLabs] Upgrade corosync problem

[Jan Pokorný]

On 29/06/18 19:13 +0200, Salvatore D'angelo wrote:
> Good to know. I'll try it. I'll try to work on VM too.

If that won't work, you can also try:

  docker run ... --ulimit memlock=33554432 ...

where 32768 (kiB) may still be not enough (assuming the default
of 16384), hard to say, since proper root user may normally be
bypassing any such limitations.

Good luck.

> Il Ven 29 Giu 2018, 5:46 PM Jan Pokorný <jpokorny at redhat.com> ha scritto:
> 
>> 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
>>> executions.
>>> 
>>> 
>>> 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
>>> command.
>>> 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.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20180629/13ac4bc8/attachment-0002.sig>