Re: [ClusterLabs] Problem with pacemaker init.d script

[Jan Pokorný]

On 12/07/18 18:54 +0200, Jan Pokorný wrote:
>>> On 12 Jul 2018, at 15:47, Jan Pokorný  wrote:
>>> On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
>>> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
 [...] question is pacemaker install
 /etc/init.d/pacemaker script but its header is not compatible
 with newer system that uses LSB.
>>> 
>>> Combining LSB and "newer system" in one sentence is sort of ridiculous
>>> since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
>>> explain headers like Default-Start [1]), and the concept of system
>>> initialization in the Linux context was gradually refined with
>>> projects like upstart and systemd.  
> 
> Sorry, forgot:

(sending faster than rechecking)

[1] https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/initscrcomconv.html

-- 
Nazdar,
Jan (Poki)


pgprpiXZzoGqz.pgp
Description: PGP signature
___
Users mailing list: Users@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Jan Pokorný]

On 12/07/18 16:51 +0200, Salvatore D'angelo wrote:
> My “talent” as you said comes from a bad knowledge of system vs upstart vs 
> sysV mechanism.

Rule of thumb: aim at what's a first class citizen in your
distribution/system of choice -- for your particular situation,
others already indicated the choice is obvious.

Once you know which init system to target, you can become proficient
pretty fast with the basics (immediate start/stop, on-boot enablement
or otherwise).

> Let me only underline that I compile directly on target system and
> not a different machine.

That simplifies the surface, which is always better for
troubleshooting.

> Moreover, all ./configure requirements are met because when this
> didn’t happen the ./configure stopped (at least this is what I
> expected).

Rather a false assumption: some "features" are merely optional, meaning
the relevant functionality and/or files will simply be skipped, without
any fatal stop/big noise.  That's intentional and desired, one size
doesn't fit all.

> However, I’ll pay more attention the next time I’ll run ./configure
> to the output.

Great.

> For the moment, I have the workaround mentioned in the previous
> email because I only developed a proof of concepts.
> When we will start to create production code I’ll try to better
> understand how systemd works and how to use it to fix my issue.

Note that systemd per se is not causing any interferences, it's just
a mix of shortcomings (starting with a likely lack of some files in
your installation and ending with pettiness of LSB compatibility
software) that is to be blamed.  Luckily, it's solvable.

On the contrary, with systemd in the picture, you'll get some small
benefits incl. a possibility to run services through their native
systemd unit files (a tuned collection of directives determining how
to optimally run particular daemons) when provided, amongst others.
> 
>> On 12 Jul 2018, at 15:47, Jan Pokorný  wrote:
>> On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
>> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>>> [...] question is pacemaker install
>>> /etc/init.d/pacemaker script but its header is not compatible
>>> with newer system that uses LSB.
>> 
>> Combining LSB and "newer system" in one sentence is sort of ridiculous
>> since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
>> explain headers like Default-Start [1]), and the concept of system
>> initialization in the Linux context was gradually refined with
>> projects like upstart and systemd.  

Sorry, forgot:

[1] 

-- 
Nazdar,
Jan (Poki)


pgphpxBhdizDM.pgp
Description: PGP signature
___
Users mailing list: Users@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Salvatore D'angelo]

Hi Jan,

My “talent” as you said comes from a bad knowledge of system vs upstart vs sysV 
mechanism.
Let me only underline that I compile directly on target system and not a 
different machine.
Moreover, all ./configure requirements are met because when this didn’t happen 
the ./configure stopped (at least this is what I expected).
However, I’ll pay more attention the next time I’ll run ./configure to the 
output.

For the moment, I have the workaround mentioned in the previous email because I 
only developed a proof of concepts.
When we will start to create production code I’ll try to better understand how 
systemd works and how to use it to fix my issue.
Thank you for support.

> On 12 Jul 2018, at 15:47, Jan Pokorný  wrote:
> 
> Hello Salvatore,
> 
> we can cope with that without much trouble, but you seem to have
> a talent to present multiple related issues at once, or perhaps
> to start solving the problems from the too distant point :-) 
> 
> As mentioned, that's also fine, but let's separate them...
> 
> On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>> [...] question is pacemaker install
>> /etc/init.d/pacemaker script but its header is not compatible
>> with newer system that uses LSB.
> 
> Combining LSB and "newer system" in one sentence is sort of ridiculous
> since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
> explain headers like Default-Start [1]), and the concept of system
> initialization in the Linux context was gradually refined with
> projects like upstart and systemd.  
> 
> What may have changed between older and newer Ubuntu, though,
> towards less compatibility (or contrary, more strictness on the
> headers/initscript meta-data) is that the compatibility support
> scripts/translators are written from scratch, leaving relaxed
> approach (the standard is also not that strict) behind ... or not,
> and this is just a new regression subsequently fixed later on:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588868
> 
> which matches your:
> 
>>> 11.07.2018 21:01, Salvatore D'angelo пишет:
 [...] system find that sysV is installed and try to leverage on
 update-rc.d scripts and the failure occurs:
 
 root@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.
> 
> So I'd be inclined to think the existing initscripts can be used just
> fine in bug-free LSB initialization scenarios.  It'd be hence just
> your choice whether to apply the workaround for sysv-rc bug (?) that
> you've presented.
> 
> Anyway, as mentioned:
> 
>> On 11 Jul 2018, at 18:40, Andrei Borzenkov 
>> wrote:
>>> 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.
> 
> and
> 
>> On 11 Jul 2018, at 21:07, Andrei Borzenkov  wrote:
>>> Then you built corosync without systemd integration. systemd will prefer
>>> native units.
> 
> You shouldn't be using, not even indirectly, initscripts with
> systemd-enabled deployments, otherwise you ask for various dependency
> mismatches and other complications.
> 
> Which gets us to another problem in pacemaker context:
> 
> On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
>> when I run “make install” anything is created for systemd env.
> 
> (presuming anything ~ nothing), because as Ken mentioned:
> 
> On 11 Jul 2018, at 19:29, Ken Gaillot  wrote:
> With Ubuntu 16, you should use "systemctl enable pacemaker" instead
> of update-rc.d.
> 
> So, if you haven't tried to build pacemaker on a system differing to
> the target one in some build-time important aspects, then I can guess
> you just hadn't ensured you have all systemd-related requisities
> installed at the time you've run "./configure".  Currently, it boils
> down to libdbus-1 library + development files (looks covered with
> "libdbus-1-dev" package) & working "systemctl" command from systemd
> suite.
> 
> Frankly, when people go the path of custom compilations, it's assumed
> they will get familiar with the build system tools, or at the very
> least will try to make a reason from what's written to the terminal
> -- Salvatore, if you were careful enough, you could observe lines
> like these if you had all such prerequisites right (alternatively,
> review config.log file):
> 
>> checking for DBUS... yes
>> checking for DBusBasicValue... yes
>> checking for systemd version query result via dbus-send... string "238"
>> checking whether to enable support for managing resources via systemd... yes
>> checking for systemd path for system unit files...  /usr/lib/systemd/system
> 
> If there was "no" or "borked" indications with some o

Re: [ClusterLabs] Problem with pacemaker init.d script

[Jan Pokorný]

Hello Salvatore,

we can cope with that without much trouble, but you seem to have
a talent to present multiple related issues at once, or perhaps
to start solving the problems from the too distant point :-) 

As mentioned, that's also fine, but let's separate them...

On 11/07/18 18:43 +0200, Salvatore D'angelo wrote:
 On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
> [...] question is pacemaker install
> /etc/init.d/pacemaker script but its header is not compatible
> with newer system that uses LSB.

Combining LSB and "newer system" in one sentence is sort of ridiculous
since LSB dates back to 2002 (LSB 1.1 seems to be first to actually
explain headers like Default-Start [1]), and the concept of system
initialization in the Linux context was gradually refined with
projects like upstart and systemd.  

What may have changed between older and newer Ubuntu, though,
towards less compatibility (or contrary, more strictness on the
headers/initscript meta-data) is that the compatibility support
scripts/translators are written from scratch, leaving relaxed
approach (the standard is also not that strict) behind ... or not,
and this is just a new regression subsequently fixed later on:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588868

which matches your:

>> 11.07.2018 21:01, Salvatore D'angelo пишет:
>>> [...] system find that sysV is installed and try to leverage on
>>> update-rc.d scripts and the failure occurs:
>>> 
>>> root@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.

So I'd be inclined to think the existing initscripts can be used just
fine in bug-free LSB initialization scenarios.  It'd be hence just
your choice whether to apply the workaround for sysv-rc bug (?) that
you've presented.

Anyway, as mentioned:

> On 11 Jul 2018, at 18:40, Andrei Borzenkov 
> wrote:
>> 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.

and

> On 11 Jul 2018, at 21:07, Andrei Borzenkov  wrote:
>> Then you built corosync without systemd integration. systemd will prefer
>> native units.

You shouldn't be using, not even indirectly, initscripts with
systemd-enabled deployments, otherwise you ask for various dependency
mismatches and other complications.

Which gets us to another problem in pacemaker context:

 On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
> when I run “make install” anything is created for systemd env.

(presuming anything ~ nothing), because as Ken mentioned:

 On 11 Jul 2018, at 19:29, Ken Gaillot  wrote:
 With Ubuntu 16, you should use "systemctl enable pacemaker" instead
 of update-rc.d.

So, if you haven't tried to build pacemaker on a system differing to
the target one in some build-time important aspects, then I can guess
you just hadn't ensured you have all systemd-related requisities
installed at the time you've run "./configure".  Currently, it boils
down to libdbus-1 library + development files (looks covered with
"libdbus-1-dev" package) & working "systemctl" command from systemd
suite.

Frankly, when people go the path of custom compilations, it's assumed
they will get familiar with the build system tools, or at the very
least will try to make a reason from what's written to the terminal
-- Salvatore, if you were careful enough, you could observe lines
like these if you had all such prerequisites right (alternatively,
review config.log file):

> checking for DBUS... yes
> checking for DBusBasicValue... yes
> checking for systemd version query result via dbus-send... string "238"
> checking whether to enable support for managing resources via systemd... yes
> checking for systemd path for system unit files...  /usr/lib/systemd/system

If there was "no" or "borked" indications with some of these lines,
you can be sure that you didn't satisfy some preconditions for
pacemaker to count on systemd -- service files won't be installed
in that case.  Some (though not all) of these decisions can be
overridden with "./configure  --enable-systemd".

If you observe something not matching the expectations, tell us
_what you've tried_ to get it working as expected (please do not
expect a micro-guidance, since in that case you'll be clearly
better served with distro-provided packages).

Once the pacemaker side is resolved, we can move on to corosync. 

* * *

Btw. I've attempted to get rid of a rather crazy (and now also
apparently error-prone) multi-init-support static deployments
of pacemaker:
https://github.com/ClusterLabs/pacemaker/pull/1175
though it was rejected on dubious grounds (not first, nor last).

Discussing arising ambiguity here, I take the opportunity to solicit
feedback 

Re: [ClusterLabs] Problem with pacemaker init.d script

[Salvatore D'angelo]

Hi,

I have a cluster on three bare metal and I use two busters nodes to keep 
walking files and backup store on an object store.
I use Docker for test purpose.

Here the possible upgrade scenario you can apply:
http://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-upgrade.html

I used Rolling method or node by node because I always have a master up and 
running (there is few ms of downtime when switch occurs and I have a connection 
pool then immediately switch to the new master).

You need to understand that if if Rolling is only suggested for minor upgrade, 
2.0.0 didn’t introduced anything new, only removed deprecated features + bug 
fix on top of 1.1.18 code.
1.1.19 contains back porting of these fix (but not the remove of deprecated 
features). So you can apply this upgrade method even if you want to move to 
2.0.0. 
We decide to go on 1.1.19. GA code was release two days ago.

Read all threads with my name in June and July here:
https://oss.clusterlabs.org/mailman/listinfo/users

you’ll find useful info I had to solve. 

On each node I do the following:
1. I first download source code for old pacemaker, corosync, crmsh and 
resource agents
2. mae uninstall on all of them
3. download source of new code (I verified on Ubuntu 14.04 library must 
not be upgraded, for 16.04 I just downloaded the new version of the libraries)
4. follow the build instruction for all the 4 projects. Resource agents 
is not documented, I do:
autoreconf -i -v
./configure
make
make install

for the other simply:
./autogen.sh
./configure
make
make install

5.  then do again the configuration steps you did when created the 
cluster with 1.1.14

I used Docker for test because it minimise the test time. If I do something 
wrong and situation is not recoverable I recreate the cluster in minutes.
You can do the same with virtual machine and Vagrant. But I consider this 
critical.

That’s all. 


> On 12 Jul 2018, at 00:31, Casey & Gina  wrote:
> 
>> 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.
> 
> Forgive me for interjecting, but how did you upgrade on Ubuntu?  I'm 
> frustrated with limitations in 1.1.14 (particularly in PCS so not sure if 
> it's relevant), and Ubuntu is ignoring my bug reports, so it would be great 
> to upgrade if possible.  I'm using Ubuntu 16.04.
> 
> Best wishes,
> -- 
> Casey
> ___
> Users mailing list: Users@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@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Valentin Vidic]

On Wed, Jul 11, 2018 at 04:31:31PM -0600, Casey & Gina wrote:
> Forgive me for interjecting, but how did you upgrade on Ubuntu?  I'm
> frustrated with limitations in 1.1.14 (particularly in PCS so not sure
> if it's relevant), and Ubuntu is ignoring my bug reports, so it would
> be great to upgrade if possible.  I'm using Ubuntu 16.04.

pcs is a single package in python and ruby so it should be possible to
try a newer version and see if it helps.

-- 
Valentin
___
Users mailing list: Users@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Casey & Gina]

> 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.

Forgive me for interjecting, but how did you upgrade on Ubuntu?  I'm frustrated 
with limitations in 1.1.14 (particularly in PCS so not sure if it's relevant), 
and Ubuntu is ignoring my bug reports, so it would be great to upgrade if 
possible.  I'm using Ubuntu 16.04.

Best wishes,
-- 
Casey
___
Users mailing list: Users@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Salvatore D'angelo]

Sorry replied too soon. 
Since disabling the update-rc.d command I assume the build process creates the 
services.
The only problem is that enabling them with systemctl does not work because it 
leverage on update-rc.d command that works only if LSB header container at 
least one run level.

For the moment the only fix I see is to  manipulate these init.d scripts by 
myself hoping they will be fixed in pacemaker/corosync.

> On 11 Jul 2018, at 23:18, Salvatore D'angelo  wrote:
> 
> Hi,
> 
> I solved the issue (I am not sure to be honest) simply removing the 
> update-rc.d command.
> I noticed I can start the corosync and pacemaker services with:
> 
> service corosync start
> service pacemaker start
> 
> I am not sure if they have been enabled at book (on Docker is not easy to 
> test).
> I do not know if pacemaker build creates automatically these services and 
> then it is required extra work to make them available at book.
> 
>> On 11 Jul 2018, at 21:07, Andrei Borzenkov > > wrote:
>> 
>> 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.
> 
> How can I build them with system integration?
> 
>> 
>>> 
>>> root@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 …
> 
> What do you suggest?
> 
>> 
>> 
>> 
 On 11 Jul 2018, at 19:29, Ken Gaillot >>> > 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 > >
>> 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 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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Salvatore D'angelo]

Hi,

I solved the issue (I am not sure to be honest) simply removing the update-rc.d 
command.
I noticed I can start the corosync and pacemaker services with:

service corosync start
service pacemaker start

I am not sure if they have been enabled at book (on Docker is not easy to test).
I do not know if pacemaker build creates automatically these services and then 
it is required extra work to make them available at book.

> On 11 Jul 2018, at 21:07, Andrei Borzenkov  wrote:
> 
> 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.

How can I build them with system integration?

> 
>> 
>> root@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 …

What do you suggest?

> 
> 
> 
>>> On 11 Jul 2018, at 19:29, Ken Gaillot  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 
> 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 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@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
>> 
> 
> ___

Re: [ClusterLabs] Problem with pacemaker init.d script

[Ken Gaillot]

On Wed, 2018-07-11 at 22:07 +0300, Andrei Borzenkov wrote:
> 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@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?

Red Hat (Fedora/RHEL/CentOS) and SuSE provide enterprise support for
pacemaker, and regularly contribute code upstream, so those and their
derivatives tend to be the most stable. Debian has a good team of
volunteers that greatly improved support in the current (stretch)
release, so I suppose Ubuntu will eventually pick that up. I know
people have compiled on Arch Linux, FreeBSD, OpenBSD, and likely
others, but that usually takes some extra work.

> > 
> > 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 ...

I'm not sure. Pacemaker packages are intended to be installed without
enabling at boot, since so much configuration must be done first. So
maybe the idea was to always require someone to specify run levels. But
it does make more sense that they would be listed in the LSB header.
One reason it wouldn't have been an issue before is some older distros
use the init script's chkconfig header instead of the LSB header.


> > > On 11 Jul 2018, at 19:29, Ken Gaillot 
> > > 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  > > > > om>
> > > > > 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 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:
> > > >

Re: [ClusterLabs] Problem with pacemaker init.d script

[Valentin Vidic]

On Wed, Jul 11, 2018 at 08:01:46PM +0200, Salvatore D'angelo wrote:
> 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:
> 
> root@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?

You can try using init scripts from the Debian/Ubuntu packages for
corosync and pacemaker as they have the runlevel info included.

Another option is to get the systemd service files working and than
remove the init scripts.

-- 
Valentin
___
Users mailing list: Users@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Andrei Borzenkov]

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@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  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 
 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 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@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@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@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 
>> ___
>> User

Re: [ClusterLabs] Problem with pacemaker init.d script

[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:

root@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?

> On 11 Jul 2018, at 19:29, Ken Gaillot  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 
>>> 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 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@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@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@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 
> ___
> Users mailing list: Users@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@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Ken Gaillot]

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 
> > 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 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@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@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@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 
___
Users mailing list: Users@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Salvatore D'angelo]

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.

I am not a SysV vs System expert, hoping I haven’t said anything wrong.

> On 11 Jul 2018, at 18:40, Andrei Borzenkov  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 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@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@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@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

Re: [ClusterLabs] Problem with pacemaker init.d script

[Andrei Borzenkov]

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 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@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@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

[ClusterLabs] Problem with pacemaker init.d script

[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.
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 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@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