[Pkg-sysvinit-devel] Bug#738775: insserv: Insserv 1.16 tries to connect to systemd even though system is running on sysv-init

Felipe Sateler fsateler at debian.org
Mon Jan 18 23:24:25 UTC 2016


On Wed, 12 Feb 2014 23:04:11 +0100 Petter Reinholdtsen <pere at 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 at mybox:~# strace -o /tmp/foo insserv
> root at mybox:~# grep systemd /tmp/foo
> access("/bin/systemd", F_OK)            = -1 ENOENT (No such file or directory)
> root at mybox:~# touch /bin/systemd
> root at 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 at 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).



More information about the Pkg-sysvinit-devel mailing list