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 <arvidj...@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 <arvidj...@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 <kgail...@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)
pgpXMcU3aNEun.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
