[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