[opensuse] Systemd doesn't start Altair license manager
After latest update 12.2 of Altair license manager (a commercial third-party software) Systemd doesn't start the license manager service anymore. Setup: * openSUSE Leap 42.1 x86_64 * Altair License Manager-LMX-12.2 for RHEL 4,5,6 and SLES 10,11 on x86_64 processors (64-bit) (see https://connect.altair.com/CP/downloads.html) The license manager setup installs a traditional start/stop script /etc/init.d/altairlmxd (see copy here: http://paste.opensuse.org/30183920) The only change between the non-starting version 12.2 and the starting 12.1 script is the version number itself: diff --git a/init.d/altairlmxd b/init.d/altairlmxd index 9444f45..a62a0fe 100755 --- a/init.d/altairlmxd +++ b/init.d/altairlmxd @@ -18,11 +18,11 @@ ### END INIT INFO ALTAIR_LMX=1 -ALTAIR_LMX_DIR="/usr/local/altair/licensing12.1" +ALTAIR_LMX_DIR="/usr/local/altair/licensing12.2" export ALTAIR_LMX_DIR ##Add library path for license server 12.0 -LD_LIBRARY_PATH=/usr/local/altair/licensing12.1/bin +LD_LIBRARY_PATH=/usr/local/altair/licensing12.2/bin export LD_LIBRARY_PATH ### Uncomment and set to a username if you would like to run the license server I enabled the service after installation with "systemctl enable altairlmxd.service". Anyway, the service does not start automatically during boot. "journalctl -b" doesn't contain messages about "altairlmxd". "systemd-analyse blame" also has no messages. Manual starting with "systemctl enable altairlmxd.service". How I can debug this problem? Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bjoern Voigt wrote:
After latest update 12.2 of Altair license manager (a commercial third-party software) Systemd doesn't start the license manager service anymore.
Setup:
* openSUSE Leap 42.1 x86_64 * Altair License Manager-LMX-12.2 for RHEL 4,5,6 and SLES 10,11 on x86_64 processors (64-bit) (see https://connect.altair.com/CP/downloads.html)
The license manager setup installs a traditional start/stop script /etc/init.d/altairlmxd (see copy here: http://paste.opensuse.org/30183920)
The only change between the non-starting version 12.2 and the starting 12.1 script is the version number itself:
diff --git a/init.d/altairlmxd b/init.d/altairlmxd index 9444f45..a62a0fe 100755 --- a/init.d/altairlmxd +++ b/init.d/altairlmxd @@ -18,11 +18,11 @@ ### END INIT INFO
ALTAIR_LMX=1 -ALTAIR_LMX_DIR="/usr/local/altair/licensing12.1" +ALTAIR_LMX_DIR="/usr/local/altair/licensing12.2" export ALTAIR_LMX_DIR
##Add library path for license server 12.0 -LD_LIBRARY_PATH=/usr/local/altair/licensing12.1/bin +LD_LIBRARY_PATH=/usr/local/altair/licensing12.2/bin export LD_LIBRARY_PATH
### Uncomment and set to a username if you would like to run the license server
I enabled the service after installation with "systemctl enable altairlmxd.service".
Anyway, the service does not start automatically during boot. "journalctl -b" doesn't contain messages about "altairlmxd". "systemd-analyse blame" also has no messages.
Manual starting with "systemctl enable altairlmxd.service".
How I can debug this problem?
What does "systemctl status altairlmxd.service" say? -- Per Jessen, Zürich (7.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bjoern Voigt wrote:
After latest update 12.2 of Altair license manager (a commercial third-party software) Systemd doesn't start the license manager service anymore.
Setup:
* openSUSE Leap 42.1 x86_64 * Altair License Manager-LMX-12.2 for RHEL 4,5,6 and SLES 10,11 on x86_64 processors (64-bit) (see https://connect.altair.com/CP/downloads.html)
The license manager setup installs a traditional start/stop script /etc/init.d/altairlmxd (see copy here: http://paste.opensuse.org/30183920)
The only change between the non-starting version 12.2 and the starting 12.1 script is the version number itself:
diff --git a/init.d/altairlmxd b/init.d/altairlmxd index 9444f45..a62a0fe 100755 --- a/init.d/altairlmxd +++ b/init.d/altairlmxd @@ -18,11 +18,11 @@ ### END INIT INFO
ALTAIR_LMX=1 -ALTAIR_LMX_DIR="/usr/local/altair/licensing12.1" +ALTAIR_LMX_DIR="/usr/local/altair/licensing12.2" export ALTAIR_LMX_DIR
##Add library path for license server 12.0 -LD_LIBRARY_PATH=/usr/local/altair/licensing12.1/bin +LD_LIBRARY_PATH=/usr/local/altair/licensing12.2/bin export LD_LIBRARY_PATH
### Uncomment and set to a username if you would like to run the license server
I enabled the service after installation with "systemctl enable altairlmxd.service".
Anyway, the service does not start automatically during boot. "journalctl -b" doesn't contain messages about "altairlmxd". "systemd-analyse blame" also has no messages.
Manual starting with "systemctl enable altairlmxd.service".
How I can debug this problem? The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd I do not exactly know, why this is necessary. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd. Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them. -- After all is said and done, more is said than done -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them.
At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work. -- Per Jessen, Zürich (5.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/25/2016 02:18 PM, Per Jessen wrote:
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them.
At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work.
Apparently not. At least not unless you remember to runs some relatively obscure command after install, which should be done by the Altair installer. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-25 23:30, John Andersen wrote:
On 04/25/2016 02:18 PM, Per Jessen wrote:
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them.
At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work.
Apparently not. At least not unless you remember to runs some relatively obscure command after install, which should be done by the Altair installer.
No. If you need to do that it must be because the init file is not compliant. Perhaps the OP could post the entire file. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-25 23:30, John Andersen wrote:
On 04/25/2016 02:18 PM, Per Jessen wrote:
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary. It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them. At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work.
Apparently not. At least not unless you remember to runs some relatively obscure command after install, which should be done by the Altair installer. No. If you need to do that it must be because the init file is not compliant.
Perhaps the OP could post the entire file. I already posted the start/stop script: http://paste.opensuse.org/30183920
I compared the header with /etc/init.d/courier-imap from courier-imap-4.16.2-1.3.x86_64 (Leap 42.1) and did not found errors. But Courier IMAP has both, a /etc/init.d/courier-imap SysV start/stop script and a Systemd service /usr/lib/systemd/system/courier-imap.service: # rpm -ql courier-imap-4.16.2-1.3.x86_64 /etc/init.d/courier-imap /etc/init.d/courier-imap-ssl [...] /usr/lib/systemd/system/courier-imap-ssl.service /usr/lib/systemd/system/courier-imap.service Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 00:20, Bjoern Voigt wrote:
Carlos E. R. wrote:
Perhaps the OP could post the entire file. I already posted the start/stop script: http://paste.opensuse.org/30183920
Oh, sorry. It seems normal, but it misses this line: . /etc/rc.status That line is the one that passes control to systemd when needed, and it is missing. Also I see checks in the script for "/etc/SuSE-release", but the code only checks SLE, not openSUSE. Also, even before systemd, it was not enough to place a file in init.d, and create the symlinks: it was needed to run a program to insert the service in the chain: typically "chkconfig". Maybe the installation script forgot to do that. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
Also, even before systemd, it was not enough to place a file in init.d, and create the symlinks: it was needed to run a program to insert the service in the chain: typically "chkconfig". Maybe the installation script forgot to do that.
chkconfig / insserv / systemctl enable Yes, that's exactly why I asked to OP to post the output from "systemctl status altairlmxd". -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 04/25/2016 02:18 PM, Per Jessen wrote:
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them.
At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work.
Apparently not. At least not unless you remember to runs some relatively obscure command after install, which should be done by the Altair installer.
If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are. -- Per Jessen, Zürich (8.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but
Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called.
I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Yes, but you may need to use old insserv/chkconfig tool in this case, I am not sure if systemctl enable/disable still supports legacy scripts. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but
Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called.
What happens when it isn't called? I often install the HP Proliant Support Pack which is not specifically openSUSE "compliant", but it works perfectly fine. It has 2-3 init scripts.
I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Yes, but you may need to use old insserv/chkconfig tool in this case, I am not sure if systemctl enable/disable still supports legacy scripts.
I think it does, but I haven't tried it for a while. -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but
Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called.
What happens when it isn't called? I often install the HP Proliant Support Pack which is not specifically openSUSE "compliant", but it works perfectly fine. It has 2-3 init scripts.
Ditto for the 3ware array management daemon, also works fine. I have to deal with LSB init scripts for quite some time to come. Manufacturers (in my case HP, IBM, 3ware) do not upgrade or fix their software packages. You want an update, you buy a new card or a new box. Even then there's often no (open)SUSE-specific support.
I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Yes, but you may need to use old insserv/chkconfig tool in this case, I am not sure if systemctl enable/disable still supports legacy scripts.
I think it does, but I haven't tried it for a while.
Just tested it on Leap421 - stork2:~ # systemctl disable tdm2 tdm2.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig tdm2 off stork2:~ # systemctl enable tdm2 tdm2.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig tdm2 on -- Per Jessen, Zürich (8.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Apr 26, 2016 at 9:55 AM, Per Jessen <per@computer.org> wrote:
Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but
Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called.
What happens when it isn't called? I often install the HP Proliant Support Pack which is not specifically openSUSE "compliant", but it works perfectly fine. It has 2-3 init scripts.
It probably simply installs initscript as before without converting it to systemd service. "rpm -q --scripts" is your friend here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:55 AM, Per Jessen <per@computer.org> wrote:
Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called. What happens when it isn't called? I often install the HP Proliant Support Pack which is not specifically openSUSE "compliant", but it works perfectly fine. It has 2-3 init scripts.
It probably simply installs initscript as before without converting it to systemd service. "rpm -q --scripts" is your friend here. Unfortunately the Altair license manager is not available as RPM. The installer is build with InstallAnywhere. The setup file altair_licensing_12.2.0.linux_x64.bin is a shell script with an included binary payload. After executing the shell script a interactive Java/Swing installer starts. Shell scripts can be found in XML files e.g. in InstallScript.iap_xml:
<property name="script"> <string><![CDATA[#!/bin/sh $USER_INSTALL_DIR$/bin/service_helper start]]></string> </property> Debugging this is probably no fun. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 08:31, Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but
Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called.
This particular application is made for SLE. The script has detection for some SLE versions ( < or > than 10); as what it finds is openSUSE, not SLE, and the user has Leap 42.1, it may think that it has SLE 42, much bigger than 10. Who knows what it does - no, I stopped analyzing there ;-) Possibly the installation script did not do proper customization for SUSE.
I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Yes, but you may need to use old insserv/chkconfig tool in this case, I am not sure if systemctl enable/disable still supports legacy scripts.
Yes, it has to. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-26 08:31, Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but
Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called.
This particular application is made for SLE. The script has detection for some SLE versions ( < or > than 10); as what it finds is openSUSE, not SLE, and the user has Leap 42.1, it may think that it has SLE 42, much bigger than 10. Who knows what it does - no, I stopped analyzing there ;-)
The start-upo is roughly this: if system!=AIX then start lmx-serv ... If system=linux, touch lock-file If system>=sles10, touch lock-file again
Possibly the installation script did not do proper customization for SUSE.
Perhaps, but Björn said he upgraded the license manager, not the system, so I guess it must have been running before. -- Per Jessen, Zürich (11.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 12:21, Per Jessen wrote:
Carlos E. R. wrote:
The start-upo is roughly this:
if system!=AIX then start lmx-serv ... If system=linux, touch lock-file If system>=sles10, touch lock-file again
What does it do on Leap? :-?
Possibly the installation script did not do proper customization for SUSE.
Perhaps, but Björn said he upgraded the license manager, not the system, so I guess it must have been running before.
Yes, but... :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-26 12:21, Per Jessen wrote:
Carlos E. R. wrote:
The start-upo is roughly this:
if system!=AIX then start lmx-serv ... If system=linux, touch lock-file If system>=sles10, touch lock-file again
What does it do on Leap? :-?
start lmx-serv <args> touch lock-file touch lock-file (version becomes 42). -- Per Jessen, Zürich (11.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 12:31, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-04-26 12:21, Per Jessen wrote:
Carlos E. R. wrote:
The start-upo is roughly this:
if system!=AIX then start lmx-serv ... If system=linux, touch lock-file If system>=sles10, touch lock-file again
What does it do on Leap? :-?
start lmx-serv <args> touch lock-file touch lock-file
(version becomes 42).
Seems innocent enough... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen <per@computer.org> wrote:
If anything, systemd-sysv-convert should be invoked automagically, but Package has to call it manually (it is done via macros, but these macros must be explicitly included in spec). And those macros are expanded when package is created, so unless it was built for (open)SUSE and using (open)SUSE macros, this tool won't be called. This particular application is made for SLE. The script has detection for some SLE versions ( < or > than 10); as what it finds is openSUSE, not SLE, and the user has Leap 42.1, it may think that it has SLE 42, much bigger than 10. Who knows what it does - no, I stopped analyzing
On 2016-04-26 08:31, Andrei Borzenkov wrote: there ;-) The start-upo is roughly this:
if system!=AIX then start lmx-serv ... If system=linux, touch lock-file If system>=sles10, touch lock-file again
Possibly the installation script did not do proper customization for SUSE. Perhaps, but Björn said he upgraded the license manager, not the system, so I guess it must have been running before. Yes, but if I rethink, this isn't correct. I installed Altair License manager 12.1 in March 2015. I had openSUSE 13.2 at this time. I upgraded
Per Jessen wrote: the server in January 2016 to Leap 42.1. So slight differences in the behavior of Systemd between 13.2 and Leap 42.1 can be a possible cause. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 25, 2016 11:16:40 PM PDT, Per Jessen <per@computer.org> wrote:
John Andersen wrote:
On 04/25/2016 02:18 PM, Per Jessen wrote:
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them.
At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work.
Apparently not. At least not unless you remember to runs some relatively obscure command after install, which should be done by the Altair installer.
If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Once again I say, Apparently not. Because it didn't work "as they are" for the OP. And the solution is for Altair to fix their install process, to either work with existing unit scripts or add the systems targets. Or both. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On April 25, 2016 11:16:40 PM PDT, Per Jessen <per@computer.org> wrote:
John Andersen wrote:
On 04/25/2016 02:18 PM, Per Jessen wrote:
John Andersen wrote:
On 04/25/2016 01:26 PM, Bjoern Voigt wrote:
The service now starts automatically after calling once:
systemd-sysv-convert --save altairlmxd
I do not exactly know, why this is necessary.
It is necessary because Altair hasn't yet recognized that the entire world has gone Systemd. Even the Raspberry Pi linux distro now uses systemd.
Altair is too lazy to revise their packages to operate correctly in the modern world (except for those few distros that are hold-outs). You should file a bug report with them.
At most a feature request - systemd provides sysvinit compatibility, LSB init scripts should continue to work.
Apparently not. At least not unless you remember to runs some relatively obscure command after install, which should be done by the Altair installer.
If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Once again I say, Apparently not. Because it didn't work "as they are" for the OP.
Right, but we don't who is to blame, the init script, systemd or the OP.
And the solution is for Altair to fix their install process, to either work with existing unit scripts or add the systems targets. Or both.
According to what Björn posted, the init script worked before the update, and the diff shows no significant changes. Anyway, Björn wanted to know how to debug this - "systemctl status service" will tell you how systemd sees things. That ought to be a good place to start. -- Per Jessen, Zürich (9.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
According to what Björn posted, the init script worked before the update, and the diff shows no significant changes. Anyway, Björn wanted to know how to debug this -
"systemctl status service" will tell you how systemd sees things. That ought to be a good place to start.
for LSB services, "systemctl status" does not tell us if a service is enabled or disabled, so please also run "chkconfig altairlmxd". -- Per Jessen, Zürich (8.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
According to what Björn posted, the init script worked before the update, and the diff shows no significant changes. Anyway, Björn wanted to know how to debug this -
"systemctl status service" will tell you how systemd sees things. That ought to be a good place to start. for LSB services, "systemctl status" does not tell us if a service is enabled or disabled, so please also run "chkconfig altairlmxd". Sorry, I switched from Leap 42.1 to Tumbleweed because I currently can't test the Leap 42.1 server.
Directly after installation I have: # systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # chkconfig altairlmxd altairlmxd 5 After calling "systemctl enable": # systemctl enable altairlmxd altairlmxd.service is not a native service, redirecting to systemd-sysv-install Executing /usr/lib/systemd/systemd-sysv-install enable altairlmxd Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. If you want to list systemd services use 'systemctl list-unit-files'. To see services enabled on particular target use 'systemctl list-dependencies [target]'. altairlmxd 0:off 1:off 2:off 3:off 4:off 5:on 6:off # systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # chkconfig altairlmxd altairlmxd 5 The Leap 42.1 system runs without GUI (runlevel 3). But the license manager seems to run only at runlevel 5. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bjoern Voigt wrote:
Per Jessen wrote:
Per Jessen wrote:
According to what Björn posted, the init script worked before the update, and the diff shows no significant changes. Anyway, Björn wanted to know how to debug this -
"systemctl status service" will tell you how systemd sees things. That ought to be a good place to start. for LSB services, "systemctl status" does not tell us if a service is enabled or disabled, so please also run "chkconfig altairlmxd".
Sorry, I switched from Leap 42.1 to Tumbleweed because I currently can't test the Leap 42.1 server.
They are quite different animals.
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
That's clearly not good. It ought to find your init script in /etc/init.d/altairlmxd.
# chkconfig altairlmxd altairlmxd 5
I guess this means "only when the server reaches runlevel 5", but I'm not sure. [snip - looks good]
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
Well, that is the problem, at least on TW. I guess you have checked that "/etc/init.d/altairlmxd" does in fact exist and is executable? (grasping at straws).
# chkconfig altairlmxd altairlmxd 5
The Leap 42.1 system runs without GUI (runlevel 3). But the license manager seems to run only at runlevel 5.
Uh, the script you showed us said "Default-Start: 3 5", so it ought to start in runlevel 3, except the init script isn't found. -- Per Jessen, Zürich (10.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Bjoern Voigt wrote:
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
That's clearly not good. It ought to find your init script in /etc/init.d/altairlmxd.
Um, the script you pasted earlier: http://paste.opensuse.org/30183920 seems to be called "altairlmx_init", not "altairlmx". Which one is correct? I have just added your script to my Leap421 test system, called it "altairlmx_init" and chmod'ed +x : office34:/etc/init.d # systemctl status altairlmx_init altairlmx_init.service - LSB: Altair_Lmxd for Altair products Loaded: loaded (/etc/init.d/altairlmx_init) Active: inactive (dead) -- Per Jessen, Zürich (11.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
Bjoern Voigt wrote:
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) That's clearly not good. It ought to find your init script in /etc/init.d/altairlmxd. Um, the script you pasted earlier:
http://paste.opensuse.org/30183920
seems to be called "altairlmx_init", not "altairlmx". Which one is correct?
I have just added your script to my Leap421 test system, called it "altairlmx_init" and chmod'ed +x :
office34:/etc/init.d # systemctl status altairlmx_init altairlmx_init.service - LSB: Altair_Lmxd for Altair products Loaded: loaded (/etc/init.d/altairlmx_init) Active: inactive (dead) Thanks.
The installer installs an executable script /etc/init.d/altairlmxd: -rwxr-xr-x 1 root root 6395 Apr 26 11:53 /etc/init.d/altairlmxd The header lines say that the script has to be called altairlmx_init, but it's only a comment which is probably not evaluated. #!/bin/sh #--------------------------------------------------------------------------# # Module: altairlmx_init # Purpose: Initiallizes the Altair License Manager # Date: 04/20/10 # AltairCopyright : #--------------------------------------------------------------------------# Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bjoern Voigt wrote:
Per Jessen wrote:
Per Jessen wrote:
Bjoern Voigt wrote:
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) That's clearly not good. It ought to find your init script in /etc/init.d/altairlmxd. Um, the script you pasted earlier:
http://paste.opensuse.org/30183920
seems to be called "altairlmx_init", not "altairlmx". Which one is correct?
I have just added your script to my Leap421 test system, called it "altairlmx_init" and chmod'ed +x :
office34:/etc/init.d # systemctl status altairlmx_init altairlmx_init.service - LSB: Altair_Lmxd for Altair products Loaded: loaded (/etc/init.d/altairlmx_init) Active: inactive (dead) Thanks.
The installer installs an executable script /etc/init.d/altairlmxd: -rwxr-xr-x 1 root root 6395 Apr 26 11:53 /etc/init.d/altairlmxd
The header lines say that the script has to be called altairlmx_init, but it's only a comment which is probably not evaluated.
Ah, okay - it did seem like a stupid thing, but you never know. Well, I'm running out of thing to try - on my Leap421 test system, init scripts are picked up right away, no need to reload systemd, run systemd-sysv-convert etc. I don't understand how "systemctl status" can say # systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) yet you can start it with "systemctl start". /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 13:40, Bjoern Voigt wrote:
The header lines say that the script has to be called altairlmx_init, but it's only a comment which is probably not evaluated.
#!/bin/sh #--------------------------------------------------------------------------# # Module: altairlmx_init # Purpose: Initiallizes the Altair License Manager # Date: 04/20/10 # AltairCopyright : #--------------------------------------------------------------------------#
What matters is this other line: # Provides: AltairLmxd which is evaluated. That comment block "INIT INFO" is evaluated. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Tue, Apr 26, 2016 at 1:14 PM, Per Jessen <per@computer.org> wrote:
Bjoern Voigt wrote:
Per Jessen wrote:
Per Jessen wrote:
According to what Björn posted, the init script worked before the update, and the diff shows no significant changes. Anyway, Björn wanted to know how to debug this -
"systemctl status service" will tell you how systemd sees things. That ought to be a good place to start. for LSB services, "systemctl status" does not tell us if a service is enabled or disabled, so please also run "chkconfig altairlmxd".
Sorry, I switched from Leap 42.1 to Tumbleweed because I currently can't test the Leap 42.1 server.
They are quite different animals.
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
That's clearly not good. It ought to find your init script in /etc/init.d/altairlmxd.
No. systemd looks for unit definitions only on startup or when explicitly told to do so by "systemctl daemon-reload". Native RPM packages know it and call daemon-reload when they install/remove services. Apparently this installer does not do it.
# chkconfig altairlmxd altairlmxd 5
I guess this means "only when the server reaches runlevel 5", but I'm not sure.
You are correct. If service starts in more than one run-level it shows "on" and you need to use "chkconfig --list service" to see all of them.
[snip - looks good]
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
Well, that is the problem, at least on TW.
No, it is not. This is not native service, so systemctl redirected to chkconfig. For native services "systemctl enable" also implicitly calls daemon-reload, thus making new service known to systemd. For legacy initscripts it does not do it. Arguably it is a bug and warrants bugzilla.
I guess you have checked that "/etc/init.d/altairlmxd" does in fact exist and is executable? (grasping at straws).
# chkconfig altairlmxd altairlmxd 5
The Leap 42.1 system runs without GUI (runlevel 3). But the license manager seems to run only at runlevel 5.
Uh, the script you showed us said "Default-Start: 3 5", so it ought to start in runlevel 3, except the init script isn't found.
-- Per Jessen, Zürich (10.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Tue, Apr 26, 2016 at 1:14 PM, Per Jessen <per@computer.org> wrote:
Bjoern Voigt wrote:
Per Jessen wrote:
Per Jessen wrote:
According to what Björn posted, the init script worked before the update, and the diff shows no significant changes. Anyway, Björn wanted to know how to debug this -
"systemctl status service" will tell you how systemd sees things. That ought to be a good place to start. for LSB services, "systemctl status" does not tell us if a service is enabled or disabled, so please also run "chkconfig altairlmxd".
Sorry, I switched from Leap 42.1 to Tumbleweed because I currently can't test the Leap 42.1 server.
They are quite different animals.
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
That's clearly not good. It ought to find your init script in /etc/init.d/altairlmxd.
No. systemd looks for unit definitions only on startup or when explicitly told to do so by "systemctl daemon-reload".
That is not my experience on Leap421. I just tried it with the altairlmx_init file - only had to edit it and chmod +x it, then: office34:~ # systemctl status altairlmx_init altairlmx_init.service - LSB: Altair_Lmxd for Altair products Loaded: loaded (/etc/init.d/altairlmx_init) Active: inactive (dead) office34:/etc/init.d # l andrei-borzenkov ls: cannot access andrei-borzenkov: No such file or directory office34:/etc/init.d # touch andrei-borzenkov office34:/etc/init.d # systemctl status andrei-borzenkov andrei-borzenkov.service Loaded: masked (/etc/init.d/andrei-borzenkov) Active: inactive (dead) -- Per Jessen, Zürich (10.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 13:44, Per Jessen wrote:
office34:/etc/init.d # l andrei-borzenkov ls: cannot access andrei-borzenkov: No such file or directory office34:/etc/init.d # touch andrei-borzenkov office34:/etc/init.d # systemctl status andrei-borzenkov andrei-borzenkov.service Loaded: masked (/etc/init.d/andrei-borzenkov) Active: inactive (dead)
Same in my 13.1. Interesting. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-26 13:44, Per Jessen wrote:
office34:/etc/init.d # l andrei-borzenkov ls: cannot access andrei-borzenkov: No such file or directory office34:/etc/init.d # touch andrei-borzenkov office34:/etc/init.d # systemctl status andrei-borzenkov andrei-borzenkov.service Loaded: masked (/etc/init.d/andrei-borzenkov) Active: inactive (dead) Same in my 13.1. Interesting. The output on Tumbleweed is different ("masked" -> "not-found"):
mybox:/etc/init.d # l andrei-borzenkov ls: cannot access 'andrei-borzenkov': No such file or directory mybox:/etc/init.d # touch andrei-borzenkov mybox:/etc/init.d # systemctl status andrei-borzenkov ● andrei-borzenkov.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Apr 26, 2016 at 2:44 PM, Per Jessen <per@computer.org> wrote:
No. systemd looks for unit definitions only on startup or when explicitly told to do so by "systemctl daemon-reload".
That is not my experience on Leap421. I just tried it with the altairlmx_init file - only had to edit it and chmod +x it, then:
office34:~ # systemctl status altairlmx_init altairlmx_init.service - LSB: Altair_Lmxd for Altair products Loaded: loaded (/etc/init.d/altairlmx_init) Active: inactive (dead)
Indeed. It appears that now systemd attempts to load unit definition when asked to process explicit full unit name. Change is not entirely new, and I am not sure even if this was intentional. Note that it happens only for single unambiguous unit name. E.g. in TW systemd supports wildcards, so systemctl status foo* will *not* try to enumerate all available unit definitions, while systemctl status foo will attempt to locate and load exactly one definition for unit "foo". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 12:00, Bjoern Voigt wrote:
Per Jessen wrote:
Sorry, I switched from Leap 42.1 to Tumbleweed because I currently can't test the Leap 42.1 server.
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # chkconfig altairlmxd altairlmxd 5
After calling "systemctl enable": # systemctl enable altairlmxd altairlmxd.service is not a native service, redirecting to systemd-sysv-install Executing /usr/lib/systemd/systemd-sysv-install enable altairlmxd
Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration.
If you want to list systemd services use 'systemctl list-unit-files'. To see services enabled on particular target use 'systemctl list-dependencies [target]'.
altairlmxd 0:off 1:off 2:off 3:off 4:off 5:on 6:off
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # chkconfig altairlmxd altairlmxd 5
The Leap 42.1 system runs without GUI (runlevel 3). But the license manager seems to run only at runlevel 5.
Something went wrong. Look: ### BEGIN INIT INFO # Provides: AltairLmxd # Required-Start: $remote_fs # Should-Start: $time # Required-Stop: $remote_fs # Should-Stop: $time # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Altair_Lmxd for Altair products # Description: Altair_Lmxd for Altair products ### END INIT INFO See? it should start on level 3 and 5. Please do: chkconfig altairlmxd off chkconfig altairlmxd on chkconfig altairlmxd It may be possible that you have to add a line: . /etc/rc.status just after the block I posted above, and try again. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-26 12:00, Bjoern Voigt wrote:
Per Jessen wrote:
Sorry, I switched from Leap 42.1 to Tumbleweed because I currently can't test the Leap 42.1 server.
Directly after installation I have:
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # chkconfig altairlmxd altairlmxd 5
After calling "systemctl enable": # systemctl enable altairlmxd altairlmxd.service is not a native service, redirecting to systemd-sysv-install Executing /usr/lib/systemd/systemd-sysv-install enable altairlmxd
Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration.
If you want to list systemd services use 'systemctl list-unit-files'. To see services enabled on particular target use 'systemctl list-dependencies [target]'.
altairlmxd 0:off 1:off 2:off 3:off 4:off 5:on 6:off
# systemctl status altairlmxd ● altairlmxd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # chkconfig altairlmxd altairlmxd 5
The Leap 42.1 system runs without GUI (runlevel 3). But the license manager seems to run only at runlevel 5. Something went wrong. Look:
### BEGIN INIT INFO # Provides: AltairLmxd # Required-Start: $remote_fs # Should-Start: $time # Required-Stop: $remote_fs # Should-Stop: $time # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Altair_Lmxd for Altair products # Description: Altair_Lmxd for Altair products ### END INIT INFO
See? it should start on level 3 and 5.
Please do:
chkconfig altairlmxd off chkconfig altairlmxd on chkconfig altairlmxd
It may be possible that you have to add a line:
. /etc/rc.status
just after the block I posted above, and try again. Yes, but I can't see a difference.
Before inserting ". /etc/rc.status" I have: mybox:~ # chkconfig altairlmxd off mybox:~ # chkconfig altairlmxd on mybox:~ # chkconfig altairlmxd altairlmxd on After inserting ". /etc/rc.status" here: mybox:~ # head -n22 /etc/init.d/altairlmxd #!/bin/sh #--------------------------------------------------------------------------# # Module: altairlmx_init # Purpose: Initiallizes the Altair License Manager # Date: 04/20/10 # AltairCopyright : #--------------------------------------------------------------------------# ### BEGIN INIT INFO # Provides: AltairLmxd # Required-Start: $remote_fs # Should-Start: $time # Required-Stop: $remote_fs # Should-Stop: $time # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: Altair_Lmxd for Altair products # Description: Altair_Lmxd for Altair products ### END INIT INFO . /etc/rc.status ALTAIR_LMX=1 I have the same mybox:~ # chkconfig altairlmxd off mybox:~ # chkconfig altairlmxd on mybox:~ # chkconfig altairlmxd altairlmxd on Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 13:47, Bjoern Voigt wrote:
I have the same
mybox:~ # chkconfig altairlmxd off mybox:~ # chkconfig altairlmxd on mybox:~ # chkconfig altairlmxd altairlmxd on
try "chkconfig --list altairlmxd" -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
I have the same
mybox:~ # chkconfig altairlmxd off mybox:~ # chkconfig altairlmxd on mybox:~ # chkconfig altairlmxd altairlmxd on
On 2016-04-26 13:47, Bjoern Voigt wrote: try "chkconfig --list altairlmxd" Looks correct:
# chkconfig --list altairlmxd Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. If you want to list systemd services use 'systemctl list-unit-files'. To see services enabled on particular target use 'systemctl list-dependencies [target]'. altairlmxd 0:off 1:off 2:off 3:on 4:off 5:on 6:off Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 16:27, Bjoern Voigt wrote:
altairlmxd 0:off 1:off 2:off 3:on 4:off 5:on 6:off
Now it is enabled on levels 3 and 5 :-) An idea: as I think you edited the file slightly, I would write a comment with your initials, or some other token that you recognize instantly, that the file is modified and where. #BJ That way, when you have to install an update, you can compare the old and the new files and see fast what to modify because it is something you changed, not something that is different in the new version. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2016-04-26 08:34, John Andersen wrote:
On April 25, 2016 11:16:40 PM PDT, Per Jessen <> wrote:
John Andersen wrote:
If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Once again I say, Apparently not.
See my previous reply. The application is designed for SLE, not openSUSE. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-26 08:34, John Andersen wrote:
On April 25, 2016 11:16:40 PM PDT, Per Jessen <> wrote:
John Andersen wrote: If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are. Once again I say, Apparently not. See my previous reply. The application is designed for SLE, not openSUSE. Yes. Altair license manager is designed for SLES 11.
I thought that Leap 42.1 has a compatible base system with SLES. I do not know, if Systemd and SysV emulation is compatible too. But Leap 42.1 has a compatible base with SLES 12, not with SLES 11. Altair should update. (Btw, Windows 10 is unsupported too, but works more or less.) Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-04-26 12:08, Bjoern Voigt wrote:
Carlos E. R. wrote:
On 2016-04-26 08:34, John Andersen wrote:
On April 25, 2016 11:16:40 PM PDT, Per Jessen <> wrote:
John Andersen wrote: If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are. Once again I say, Apparently not. See my previous reply. The application is designed for SLE, not openSUSE. Yes. Altair license manager is designed for SLES 11.
I thought that Leap 42.1 has a compatible base system with SLES. I do not know, if Systemd and SysV emulation is compatible too.
But Leap 42.1 has a compatible base with SLES 12, not with SLES 11. Altair should update. (Btw, Windows 10 is unsupported too, but works more or less.)
The problem here is that the autodetection will misfire - I have not studied it that deep, but you may have to study the script and change it so that it behaves properly, and use that instead of the provided script. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2016-04-26 08:34, John Andersen wrote:
On April 25, 2016 11:16:40 PM PDT, Per Jessen <> wrote:
John Andersen wrote:
If anything, systemd-sysv-convert should be invoked automagically, but I'm not intimately famniliar with the process. To my knowledge there is no conversion "needed", LSB init scripts are supported as they are.
Once again I say, Apparently not.
See my previous reply. The application is designed for SLE, not openSUSE.
Perhaps, but it is irrelevant, the init script works with either one. There's hardly anything specific to SLE. -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Bjoern Voigt -
Carlos E. R. -
John Andersen -
Per Jessen