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

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 <arvidjaar at gmail.com>
>>>>> 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 <arvidjaar at gmail.com> 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 <kgaillot at redhat.com> 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 whether current multi-arrangement (e.g. classic initscript
will get installed along with systemd units in "make install",
possibly confusing users in a similar way to what OP deals with) is
of any value, or if it resolves to plain bloat that's better to drop.

Thanks

-- 
Nazdar,
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/20180712/bfde6d65/attachment-0002.sig>