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

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

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

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

On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen 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

Per Jessen wrote:

Andrei Borzenkov wrote:

...

On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen 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

Andrei Borzenkov wrote:

On Tue, Apr 26, 2016 at 9:55 AM, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen 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

Carlos E. R. wrote:

On 2016-04-26 08:31, Andrei Borzenkov wrote:

...

On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen 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

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

Carlos E. R. wrote:

...

...

On Tue, Apr 26, 2016 at 9:16 AM, Per Jessen 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

John Andersen wrote:

On April 25, 2016 11:16:40 PM PDT, Per Jessen 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:

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

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

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 Tue, Apr 26, 2016 at 1:14 PM, Per Jessen 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

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)

On Tue, Apr 26, 2016 at 2:44 PM, Per Jessen 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

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

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 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)

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)