description:
system: SLES12 SP3
automatic start of systemd services migrated from init system does not work.
systemd specifies that init services are migrated automatically as systemd services, this was working pretty well in SLES12 SP2.
From SP3, they are still reported by systemd as enabled (systemctl is-enabled reports ÂenabledÂ). But they are not (systemctl start is rejected as service not existing), they must be enabled manually to be started (systemctl enable creates the related service file in /run/sytemd/generator.late, then start), and must be enabled again at next boot to be started manually again. The service files are not created automatically by systemd at installation in /run/systemd/generator.late.
Moreover, they are suppressed from that directory at next boot (even after manual enable with systemctl enable), which does no more allow automatic start at system startup.
The application is a 32 bit application which requires the installation of glibc-32bit package and its dependencies prior to be installed. Remark that from SP3 a systemd-32bit package is also installed with glibc-32bit.
This is running well in SLES12 SP2. I.e. the init services are automatically enabled by systemd when they are installed and can be started directly with systemctl start (without manual enable), and they are started automatically at next boot.
I applied all patches presently available for SLES12 SP3.
should someone have an indication how to solve this or report this problem to developement, this would be welcome.
thank you very much in advance,
André
andre kouptchinsky Wrote in message:
[color=blue]
description:
system: SLES12 SP3
automatic start of systemd services migrated from init system does not
work.
systemd specifies that init services are migrated automatically as
systemd services, this was working pretty well in SLES12 SP2.
From SP3, they are still reported by systemd as enabled (systemctl
is-enabled reports ?enabled?). But they are not (systemctl start is
rejected as service not existing), they must be enabled manually to be
started (systemctl enable creates the related service file in
/run/sytemd/generator.late, then start), and must be enabled again at
next boot to be started manually again. The service files are not
created automatically by systemd at installation in
/run/systemd/generator.late.
Moreover, they are suppressed from that directory at next boot (even
after manual enable with systemctl enable), which does no more allow
automatic start at system startup.
The application is a 32 bit application which requires the installation
of glibc-32bit package and its dependencies prior to be installed.
Remark that from SP3 a systemd-32bit package is also installed with
glibc-32bit.
This is running well in SLES12 SP2. I.e. the init services are
automatically enabled by systemd when they are installed and can be
started directly with systemctl start (without manual enable), and they
are started automatically at next boot.
I applied all patches presently available for SLES12 SP3.
should someone have an indication how to solve this or report this
problem to developement, this would be welcome.
thank you very much in advance,[/color]
Was this SLES12 SP3 server installed afresh or was it upgraded
from a previous release (i.e. SLES12 SP2)?
HTH.
Simon Flood
SUSE Knowledge Partner
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
Hello Simon,
this was a VM installed afresh from SLE-12-SP3-Server-DVD-x86_64-GM-DVD1.iso downloaded from SUSE. Also all patches installed via Yast Online Update (60-days trial subscription).
André
I’m running into a similar problem.
Have a custom rc script in /etc/init.d/kickstartpostinstall.sh
Using autoyast to auto-install sles12sp2.
at end of boot, rc script (kickstartpostinstall.sh) got called & it setup the appliation.
Now, if I include the upgrades repo (we have an SMT server with sles12sp2-updates), in the autoyast config, then after boot, the kickstartpostinstall.sh never runs.
so far this issue should be reported to the concerned suse development in some way, or at least be published to potentially concerned customers (therefore I started this thread).
did you also install a glibc-32bit library to run your applications? it would be interesting to know if this issue is related to a particular configuration.
As a matter of fact, yes glibc-32 is installed.
The appliance is running oracle, and the glibc-32 is a pre-requisite.
Hello
so far this issue has to be reported to the SUSE support. If someone has an access to the support, please forward the problem.
(I only subscribed a 60 days trial for the purpose to test the new SUSE for compatiblity, not for production, hence I think I have no access to the support to report a bug).