[ClusterLabs] Problem with pacemaker init.d script

Thu Jul 12 10:51:27 EDT 2018

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ý <jpokorny at redhat.com> 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 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)
> _______________________________________________
> 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