[ClusterLabs] Problem with pacemaker init.d script

Wed Jul 11 15:07:23 EDT 2018

11.07.2018 21:01, Salvatore D'angelo пишет:
> Yes, but doing what you suggested the system find that sysV is installed and try to leverage on update-rc.d scripts and the failure occurs:

Then you built corosync without systemd integration. systemd will prefer
native units.

> 
> root at pg1:~# systemctl enable corosync
> corosync.service is not a native service, redirecting to systemd-sysv-install
> Executing /lib/systemd/systemd-sysv-install enable corosync
> update-rc.d: error: corosync Default-Start contains no runlevels, aborting.
> 
> the only fix I found was to manipulate manually the header of /etc/init.d/corosync adding the rows mentioned below.
> But this is not a clean approach to solve the issue.
> 
> What pacemaker suggest for newer distributions?
> 
> If you look at corosync code the init/corosync file does not container run levels in header.
> So I suspect it is a code problem. Am I wrong?
> 

Probably not. Description of special comments in LSB standard imply that
they must contain at least one value. Also how should service manager
know for which run level to enable service without it? It is amusing
that this problem was first found on a distribution that does not even
use SysV for years ...

>> On 11 Jul 2018, at 19:29, Ken Gaillot <kgaillot at redhat.com> wrote:
>>
>> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>>> Hi,
>>>
>>> Yes that was clear to me, but question is pacemaker install
>>> /etc/init.d/pacemaker script but its header is not compatible with
>>> newer system that uses LSB.
>>> So if pacemaker creates scripts in /etc/init.d it should create them
>>> so that they are compatible with OS supported (not sure if Ubuntu is
>>> one).
>>> when I run “make install” anything is created for systemd env.
>>
>> With Ubuntu 16, you should use "systemctl enable pacemaker" instead of
>> update-rc.d.
>>
>> The pacemaker configure script should have detected that the OS uses
>> systemd and installed the appropriate unit file.
>>
>>> I am not a SysV vs System expert, hoping I haven’t said anything
>>> wrong.
>>>
>>>> On 11 Jul 2018, at 18:40, Andrei Borzenkov <arvidjaar at gmail.com>
>>>> wrote:
>>>>
>>>> 11.07.2018 18:08, Salvatore D'angelo пишет:
>>>>> Hi All,
>>>>>
>>>>> After I successfully upgraded Pacemaker from 1.1.14 to 1.1.18 and
>>>>> corosync from 2.3.35 to 2.4.4 on Ubuntu 14.04 I am trying to
>>>>> repeat the same scenario on Ubuntu 16.04.
>>>>
>>>> 16.04 is using systemd, you need to create systemd unit. I do not
>>>> know
>>>> if there is any compatibility layer to interpret upstart
>>>> configuration
>>>> like the one for sysvinit.
>>>>
>>>>> As my previous scenario I am using Docker for test purpose before
>>>>> move to Bare metal.
>>>>> The scenario worked properly after I downloaded the correct
>>>>> dependencies versions.
>>>>>
>>>>> The only problem I experienced is that in my procedure install I
>>>>> set corosync and pacemaker to run at startup updating the init.d
>>>>> scripts with this commands:
>>>>>
>>>>> update-rc.d corosync defaults
>>>>> update-rc.d pacemaker defaults 80 80
>>>>>
>>>>> I noticed that links in /etc/rc<run level> are not created.
>>>>>
>>>>> I have also the following errors on second update-rc.d command:
>>>>> insserv: Service corosync has to be enabled to start service
>>>>> pacemaker
>>>>> insserv: exiting now!
>>>>>
>>>>> I was able to solve the issue manually replacing these lines in
>>>>> /etc/init.d/corosync and /etc/init.d/pacemaker:
>>>>> # Default-Start:
>>>>> # Default-Stop:
>>>>>
>>>>> with this:
>>>>> # Default-Start:        2 3 4 5
>>>>> # Default-Stop:         0 1 6
>>>>>
>>>>> I didn’t understand if this is a bug of corosync or pacemaker or
>>>>> simply there is a dependency missing on Ubuntu 16.04 that was
>>>>> installed by default on 14.04. I found other discussion on this
>>>>> forum about this problem but it’s not clear the solution.
>>>>> Thanks in advance for support.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list: Users at clusterlabs.org
>>>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>>>
>>>>> Project Home: http://www.clusterlabs.org
>>>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scra
>>>>> tch.pdf
>>>>> Bugs: http://bugs.clusterlabs.org
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list: Users at clusterlabs.org
>>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>>
>>>> Project Home: http://www.clusterlabs.org
>>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratc
>>>> h.pdf
>>>> Bugs: http://bugs.clusterlabs.org
>>>
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org
>>> https://lists.clusterlabs.org/mailman/listinfo/users
>>>
>>> Project Home: http://www.clusterlabs.org
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.
>>> pdf
>>> Bugs: http://bugs.clusterlabs.org
>> -- 
>> Ken Gaillot <kgaillot at redhat.com>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> https://lists.clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
> 
> 
> 
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
> 