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

[Felipe Sateler]

On Wed, 12 Feb 2014 23:04:11 +0100 Petter Reinholdtsen  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).

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

[Jan Binder]

Am Dienstag, 18. Februar 2014, 00:20:40 schrieb Petter Reinholdtsen:
 [Jan Binder]
 
  Ok, here comes the make-testsuite output.
  If debsums can be trusted, none of my initscripts were modified from
  the packaged versions.
 
 Thank you.  Still not able to reproduce it with my locally built
 insserv.  No idea why.  Will keep trying a bit more, but welcome
 ideas. :)

Yesterday I managed to get rid of the install-blocking behaviour by forcedly 
purging and reinstalling the  rpcbind package. I'm not sure why this resolves 
the problem with rpcbind being marked as missing in several runlevels.

Bug #741705 on the other hand is on a different system with systemd as pid1 
and when I tried the above method, systemd got itself stuck in a dependency 
loop and I could not even shut down the system any more.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

[Jan Binder]
 Ok, I agree that the systemd messages are gone with the SVN version
 and were not fatal:

Good.  I'll upload a les noisy version to experimental.

 Setting up initscripts (2.88dsf-49) ...
 insserv: FATAL: service dnsmasq is missed in the runlevels 2 3 4 5 to use 
 service cups-browsed
 insserv: FATAL: service rpcbind is missed in the runlevels 2 3 4 5 to use 
 service nfs-common
 insserv: exiting now!

Hm, this seem to be a problem with the complete set of scripts on your
machine.  Can you send the output from /usr/share/insserv/make-testsuite
on the machine in question?  It should allow me to reproduce your
problem.

 So it looks like the real problem is that insserv has problems with
 some script headers, especially rpcbind (see also bug #738532) and
 dnsmasq.  I don't know if there is anything wrong with those
 initscripts, but insserv dies and update-rc.d does not like that and
 returns an error which in turn dpkg does not like.

Seem to me insserv got more picky about runlevel settings.  Will have to
investigate this a bit more to be sure, as I have not seen this myself
in my testing.

 I have attached the offensive initscripts, they are from dnsmasq
 2.68-1 and rpcbind 0.2.1-2 despite not knowing what is wrong with them
 or any other part of my init configuration.

Thanks.  The output from make-testsuite is better to try to reproduce
the problem.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

[Jan Binder]
 Ok, here comes the make-testsuite output.
 If debsums can be trusted, none of my initscripts were modified from
 the packaged versions.

Thank you.  Still not able to reproduce it with my locally built
insserv.  No idea why.  Will keep trying a bit more, but welcome
ideas. :)

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

I've tried to reproduce this part of your problem report:

 * What was the outcome of this action?
 Cannot install initscripts after installing insserv 1.16 because it
 tries to connect to systemd which is present on the system but not
 used as PID 1.

I have no problem installing initscripts or any other package, even if
insserv spew out lots of error messages.  So the problem you reported
seem to be non-fatal and irrelevant for any installation problem.  Can
you tell me more about how the installation of initscripts fail?

The svn version of insserv reduces the amount of messages, but are
still printing warnings.  The behaviour do not change, as far as I can
tell.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Jan Binder]

Am Donnerstag, 13. Februar 2014, 11:11:26 schrieb Petter Reinholdtsen:
 I've tried to reproduce this part of your problem report:
  * What was the outcome of this action?
  Cannot install initscripts after installing insserv 1.16 because it
  tries to connect to systemd which is present on the system but not
  used as PID 1.
 
 I have no problem installing initscripts or any other package, even if
 insserv spew out lots of error messages.  So the problem you reported
 seem to be non-fatal and irrelevant for any installation problem.  Can
 you tell me more about how the installation of initscripts fail?
 
 The svn version of insserv reduces the amount of messages, but are
 still printing warnings.  The behaviour do not change, as far as I can
 tell.

Ok, I agree that the systemd messages are gone with the SVN version and were 
not fatal:

LANG=C apt-get install initscripts
Reading package lists... Done
Building dependency tree   
Reading state information... Done
initscripts is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 78 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up initscripts (2.88dsf-49) ...
insserv: FATAL: service dnsmasq is missed in the runlevels 2 3 4 5 to use 
service cups-browsed
insserv: FATAL: service rpcbind is missed in the runlevels 2 3 4 5 to use 
service nfs-common
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package initscripts (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initscripts
E: Sub-process /usr/bin/dpkg returned an error code (1)

So it looks like the real problem is that insserv has problems with some script 
headers,
especially rpcbind (see also bug #738532) and dnsmasq.
I don't know if there is anything wrong with those initscripts, but insserv 
dies and update-rc.d does
not like that and returns an error which in turn dpkg does not like.

I have attached the offensive initscripts, they are from dnsmasq 2.68-1 and 
rpcbind 0.2.1-2
despite not knowing what is wrong with them or any other part of my init 
configuration.


rpcbind
Description: application/shellscript


dnsmasq
Description: application/shellscript

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

[Jan Binder]

Package: insserv
Version: 1.16.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?
After having installed insserv 1.16, installing any version of initscripts
leads to the error message shown in bug #738532.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Dist-upgraded to experimental, initscrpts install failed with error.
   Tried to install any available verion of initscripts, all failed in the same 
manner.
   Forcefully removed initscripts, forcefully downgraded insserv to 1.14.
   Installing initscripts now worked.

   * What was the outcome of this action?
   Cannot install initscripts after installing insserv 1.16 because it tries to 
connect to 
   systemd which is present on the system but not used as PID 1.

   * What outcome did you expect instead?
   insserv should not fail when it cannot connect to systemd and systemd is not 
running as PID 1.
   Instead it should talk to sysv-init or whatever else it supports.


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-rc8 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages insserv depends on:
ii  libc62.18-0experimental1
ii  libdbus-1-3  1.8.0-1

insserv recommends no packages.

Versions of packages insserv suggests:
ii  bootchart2  0.14.4-3

-- debconf information:
  insserv/enable: false


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

Control: reassign 738532 insserv
Control: found 738532 1.16.0-1

[Jan Binder]
 Dear Maintainer,

Thank you for your report.  Very glad to have more testers of the new
insserv version. :)

* What led up to the situation?
 After having installed insserv 1.16, installing any version of initscripts
 leads to the error message shown in bug #738532.

How strange.  This do not happen when I test.  Do you have the
/run/systemd/private file?  I do not.

URL: https://bugs.debian.org/738532  should definitely be reassigned
to sysv-rc or insserv, and insserv seem like the most likely cause
given the messages. :)

* What was the outcome of this action?
Cannot install initscripts after installing insserv 1.16 because
it tries to connect to systemd which is present on the system but
not used as PID 1.

I do not have systemd installed.  Perhaps installing it is enough to
confuse insserv to expect it to be running?

* What outcome did you expect instead?
insserv should not fail when it cannot connect to systemd and
systemd is not running as PID 1.  Instead it should talk to
sysv-init or whatever else it supports.

I agree.

I am not sure if grave is the correct severity, given that insserv
seem to work for machines without systemd installed, but keeping it
currently as this bug is some kind of RC and definitely should not
make it into testing even if someone by mistake upload 1.16 into
unstable.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Jan Binder]

Am Mittwoch, 12. Februar 2014, 22:04:20 schrieben Sie:
 Control: reassign 738532 insserv
 Control: found 738532 1.16.0-1
 
 [Jan Binder]
 
  Dear Maintainer,
 
 Thank you for your report.  Very glad to have more testers of the new
 insserv version. :)
 
 * What led up to the situation?
 
  After having installed insserv 1.16, installing any version of
  initscripts
  leads to the error message shown in bug #738532.
 
 How strange.  This do not happen when I test.  Do you have the
 /run/systemd/private file?  I do not.
No, that particular file is not there. The parent directory, however, exists 
and has some more directories in it.

 URL: https://bugs.debian.org/738532  should definitely be reassigned
 to sysv-rc or insserv, and insserv seem like the most likely cause
 given the messages. :)
Yeah, I saw that when searching for the error message.

 * What was the outcome of this action?
 Cannot install initscripts after installing insserv 1.16 because
 it tries to connect to systemd which is present on the system but
 not used as PID 1.
 
 I do not have systemd installed.  Perhaps installing it is enough to
 confuse insserv to expect it to be running?
That might be enough.

 * What outcome did you expect instead?
 insserv should not fail when it cannot connect to systemd and
 systemd is not running as PID 1.  Instead it should talk to
 sysv-init or whatever else it supports.
 
 I agree.
 
 I am not sure if grave is the correct severity, given that insserv
 seem to work for machines without systemd installed, but keeping it
 currently as this bug is some kind of RC and definitely should not
 make it into testing even if someone by mistake upload 1.16 into
 unstable.

There are now more than ten packages in experimental/unstable that depend on 
systemd, including most of gnome, network-manager and pcscd (this pulls 
systemd for me), so that is a sensible precaution.

Greetings,
Jan Binder


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

[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;
}


Heh, a nasty way to work around this problem would be to conflict with
systemd. :) Not a sustainable option, thought. :/

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

Can you please test the svn version of the package available from
URL: svn://svn.debian.org/initscripts-ng/trunk/src/insserv  and let
me know if it solve your problem?  It improve the detection of systemd
and fix a buffer overflow.

It seem to work for me.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Jan Binder]

Am Mittwoch, 12. Februar 2014, 23:49:50 schrieb Petter Reinholdtsen:
 Can you please test the svn version of the package available from
 URL: svn://svn.debian.org/initscripts-ng/trunk/src/insserv  and let
 me know if it solve your problem?  It improve the detection of systemd
 and fix a buffer overflow.
 
 It seem to work for me.

I have trouble building a packge.
It looks like the last patch just fails:

LANG=C debuild -i -us -uc -b

 
 dpkg-buildpackage -rfakeroot -D -us -uc -i -b
dpkg-buildpackage: source package insserv
dpkg-buildpackage: source version 1.16.0-2
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Petter Reinholdtsen p...@debian.org
 dpkg-source -i --before-build insserv
dpkg-buildpackage: host architecture amd64
dpkg-source: warning: unknown information field 'Dm-Upload-Allowed' in input 
data in general section of control info file
dpkg-source: info: applying 10_nosuse.patch
dpkg-source: info: applying 11_debian_conf.patch
dpkg-source: info: applying 20_manpage_spelling.patch
dpkg-source: info: applying 21_tweak_warnings.patch
dpkg-source: info: applying 92_m68k_alignment.patch
dpkg-source: info: applying 110_portmap.patch
dpkg-source: info: applying 130_crossbuild_fixes.patch
dpkg-source: info: applying 140_debian_test_suite.patch
dpkg-source: info: applying 150_core_string_test.patch
dpkg-source: info: applying 160_manual_page_update.patch
dpkg-source: info: applying 170_if-scope.patch
dpkg-source: info: applying 180_default_runlevels.patch
dpkg-source: info: applying 190_disable_debug_output.patch
dpkg-source: info: applying 200_upstream-fixes.patch
patching file systemd.c
patching file insserv.c
Hunk #1 succeeded at 2867 (offset 4 lines).
Hunk #2 FAILED at 2942.
1 out of 2 hunks FAILED
dpkg-source: info: fuzz is not allowed when applying patches
dpkg-source: info: if patch '200_upstream-fixes.patch' is correctly applied by 
quilt, use 'quilt refresh' to update it
dpkg-source: info: restoring quilt backup files for 200_upstream-fixes.patch
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B 
.pc/200_upstream-fixes.patch/ --reject-file=-  
insserv/debian/patches/200_upstream-fixes.patch gave error exit status 1
dpkg-buildpackage: error: dpkg-source -i --before-build insserv gave error 
exit status 2
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc -i -b failed

SVN Info:

Path: .
Working Copy Root Path: /home/jan/build/insserv
URL: svn://svn.debian.org/initscripts-ng/trunk/src/insserv
Relative URL: ^/trunk/src/insserv
Repository Root: svn://svn.debian.org/initscripts-ng
Repository UUID: cb016695-7c15-0410-b0a1-921e1babe0cf
Revision: 1096
Node Kind: directory
Schedule: normal
Last Changed Author: pere
Last Changed Rev: 1096
Last Changed Date: 2014-02-12 23:48:14 +0100 (Wed, 12 Feb 2014)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Petter Reinholdtsen]

[Jan Binder]
 I have trouble building a packge.  It looks like the last patch just
 fails:

Right.  Conflict with the 190_disable_debug_output.patch patch.  Sorry
for not noticing earlier, not quite sure how I managed to build
without discovering it myself.

Anyway, fixed in svn.  Please try again.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org