Bug 728947

Even if systemd is not running but installed the service should be enabled
as otherwise switching back to systemd would miss a service.

Frederic? Why does systemctl return an error ... this should work e.g. for
a missed service enabled during a rescure boot shell session?

systemctl doesn't rely on systemd running for enable and disable command, so those commands are correctly handled even when running under sysvinit.

After checking systemctl code, returned error is coming from :
                if (!arg_no_reload)
                        r = daemon_reload(bus, args);

because by default systemctl is notifying systemd to reload its configuration.

Maybe insserv could pass --no-reload to systemctl if systemd isn't running

Created attachment 461162 [details]
Do you have meant soemthing like that?

This one uses  --no-reload for the chroot case as well as for the case
/sys/fs/cgroup/systemd is not mounted as cgroupfs

sounds good (but not tested). ludwig, could you test in your environment  ?

still complains about an error and indeed systemctl returns status 1, independent of whether --no-reload is specified or not.

unit_file_enable():

1414         /* This will return the number of symlink rules that were
1415         supposed to be created, not the ones actually created. This is
1416         useful to determine whether the passed files hat any
1417         installation data at all. */
1418         r = install_context_apply(&c, &paths, config_path, root_dir, force, changes, n_changes);

So I suppose it returns a number here and uses that as exit code.

I wonder why insserv has been patched for systemd support at all?
It's made for sysvinit. When using sysvinit rather than systemd I don't want to get botherd by any systemd related things.

Moreover the systemd integration patch invalidates the man page.
So please remove insserv's systemd patches completely.

To be user friendly I could only imagine a wrapper script which warns you like that
"Warning, insserv doesn't work for your installed systemd"

(In reply to comment #9)

This will not happen due the simple reason that *most* people
expect that insserv will enable a service even if provided by
a systemd service unit.   This enforces tht both systemd and
SysVinit will be hold in sync and the user is able to switch
the init daemon.

(In reply to comment #8)

I'd like to ask what exactly does thos return values mean?

This is an autogenerated message for OBS integration:
This bug (728947) was mentioned in
https://build.opensuse.org/request/show/92409 Factory / insserv

(In reply to comment #10)
> This will not happen due the simple reason that *most* people
> expect that insserv will enable a service even if provided by
> a systemd service unit.

On the other hand the only reason why some users stick with sysvinit at all is
that they want the old stable non-patched thing. It's a pity that deploying
systemd also affected sysvinit.

> This enforces tht both systemd and
> SysVinit will be hold in sync and the user is able to switch
> the init daemon.

Couldn't it be synced somehow when the user is actually switching?
If you do a fresh systemd install then it starts from scratch too. Morever if user is using whatever other tool to set init links then they are not in sync anyway.

What about conflicting systemd-sysvinit and sysvinit-init packages and also
update-alternative insserv?

BTW getting rid of the "systemd/sysvinit sync" could also make it possible to
remove a lot of the last systemd deps.

from the manpage, error code from systemctl is 0 : no error, non-zero, an error occurred, but it is not specified which one (and from a quick look at the code, it is usually sending EXIT_FAILURE (ie 1) when something wrong was detected..

(In reply to comment #13)

Please hold in mind tat systemd supports LSB boot scripts and therefore
insserv should be there to enable those services ... this one is one of
the major features of systemd to be able to support every LSB boot script.

(In reply to comment #15)
> Please hold in mind tat systemd supports LSB boot scripts and therefore
> insserv should be there to enable those services ... this one is one of
> the major features of systemd to be able to support every LSB boot script.

My understanding is that this support needs to be implemented within systemd and not sysvinit/insserv. When using rm/ln to configure init links systemd should respect this too if it wants to be compatible.

(In reply to comment #16)

and insserv does the rm/ln job for the admin

Please make systemd work even with the extensions and features provided by
the LSB boot scheme of the old SysVinit of openSUSE.

(In reply to comment #18)
> Please make systemd work even with the extensions and features provided by
> the LSB boot scheme of the old SysVinit of openSUSE.

this is now the case in recent openSUSE. Closing as fixed