On Wed, 12 Feb 2014 23:04:11 +0100 Petter Reinholdtsen <p...@hungry.com> wrote:
> [Jan Binder]
> >> I do not have systemd installed. Perhaps installing it is enough
> >> to confuse insserv to expect it to be running?
> > That might be enough.
>
> I found the trigger:
>
> root@mybox:~# strace -o /tmp/foo insserv
> root@mybox:~# grep systemd /tmp/foo
> access("/bin/systemd", F_OK) = -1 ENOENT (No such file or
> directory)
> root@mybox:~# touch /bin/systemd
> root@mybox:~# insserv
> insserv: can not connect systemd: Failed to connect to socket
> /run/systemd/private: No such file or directory
> process 5436: arguments to dbus_connection_close() were incorrect, assertion
> "connection != NULL" failed in file ../../dbus/dbus-connection.c line 2907.
> This is normally a bug in some application using the D-Bus library.
> process 5436: arguments to dbus_connection_unref() were incorrect, assertion
> "connection != NULL" failed in file ../../dbus/dbus-connection.c line 2794.
> This is normally a bug in some application using the D-Bus library.
> root@mybox:~#
>
> So if /bin/systemd exist, insserv change behaviour and fail if it
> can't talk to systemd. Will have to come up with a different
> detection mechanism. Anyone got any ideas? This is the current code:
>
> /*
> * Systemd support
> */
> if (access(SYSTEMD_BINARY_PATH, F_OK) == 0 && (sbus =
> systemd_open_conn())) {
>
> for (c = 0; c < argc; c++)
> forward_to_systemd (argv[c], del ? "disable": "enable", path !=
> ipath);
>
> (void)systemd_get_tree(sbus);
> systemd_close_conn(sbus);
> systemd = true;
> }
>
I don't think this will fix the issue, but the canonical check to
determine if systemd is the active init system is to check for the
existence of /run/systemd/system .
However, I'm not sure if it makes sense in a debian context to forward
requests to systemd. Systemd itself will forward requests to
update-rc.d and thus insserv, which can cause an infinite loop as
shown on #741705. At the very least it would require a means to detect
recursiveness and bail out in that case.
I'm not sure what it is supposed to accomplish, but I think this
systemd support makes sense only when systemd is the only init
supported (and thus it makes sense to add systemd units to the set of
services available to a sysv script), and systemd does not forward
enable/disable calls back to the sysv tools (thus preventing the
infinite loop).
