You know, I didn't even look closely at those warnings. Duh. Now that I
read them I see that I am being warned that I have runlevel symlinks in
1 2 3 4 5. Those aren't supposed to be there! (I run Ubuntu 15.04
upgraded from 14.04 originally.) What the aytch-e-double-hockey-stick?
Consider the history of the Debian package. Formerly when Debian had
traditional System V-style init, dh_installinit was run from
debian/rules as follows.
dh_installinit --no-start -- start 38 S . stop 89 0 6 .
Then someone filed Debian bug report #718232. As I understood it,
Debian had switched to dependency-based booting and "start" and "stop"
arguments could no longer be passed through to update-rc.d. To close
that report I changed the line to the following in May 2014.
dh_installinit --no-start
Possibly this is one of the causes of the problem, but there must be
another factor. On Debian the result of installing resolvconf is
symlinks in S, 0 and 6 as prescribed by the LSB headers in the
initscript. On my current Ubuntu 15.04 system I get the same result when
I run "update-rc.d resolvconf defaults" as root from the command line,
or upgrade the resolvconf package. So why do I have a "default" set of
rc symlinks for the resolvconf initscript on my machine? Hmm.
On my system the extraneous symlinks were created on 1 December 2014.
$ ls -l --time-style=long-iso /etc/rc2.d/*resolvconf*
lrwxrwxrwx 1 root root 20 2014-12-01 23:57 /etc/rc2.d/S01resolvconf ->
../init.d/resolvconf
This was about one half hour after, but not during, an overnight apt
update run.
----- BEGIN of snippet from /var/log/apt/history.log ------
Start-Date: 2014-12-01 23:20:52
Commandline: apt-get upgrade
Upgrade: libsystemd-login0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), ppp:amd64
(2.4.5-5.1ubuntu2, 2.4.5-5.1ubuntu2.1), libappindicator1:amd64
(12.10.1+13.10.20130920-0ubuntu4, 12.10.1+13.10.20130920-0ubuntu4.1),
systemd-services:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9),
libnautilus-extension1a:amd64 (3.10.1-0ubuntu9.3, 3.10.1-0ubuntu9.4),
unity:amd64 (7.2.2+14.04.20140714-0ubuntu1.1, 7.2.3+14.04.20140826-0ubuntu1),
libunity-core-6.0-9:amd64 (7.2.2+14.04.20140714-0ubuntu1.1,
7.2.3+14.04.20140826-0ubuntu1), libsystemd-daemon0:amd64 (204-5ubuntu20.8,
204-5ubuntu20.9), libgudev-1.0-0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9),
libpam-systemd:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), unity-services:amd64
(7.2.2+14.04.20140714-0ubuntu1.1, 7.2.3+14.04.20140826-0ubuntu1), udev:amd64
(204-5ubuntu20.8, 204-5ubuntu20.9), gir1.2-appindicator3-0.1:amd64
(12.10.1+13.10.20130920-0ubuntu4, 12.10.1+13.10.20130920-0ubuntu4.1),
gir1.2-gudev-1.0:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libappindicator3-1
:amd64 (12.10.1+13.10.20130920-0ubuntu4, 12.10.1+13.10.20130920-0ubuntu4.1),
libudev1:amd64 (204-5ubuntu20.8, 204-5ubuntu20.9), libudev1:i386
(204-5ubuntu20.8, 204-5ubuntu20.9), nautilus:amd64 (3.10.1-0ubuntu9.3,
3.10.1-0ubuntu9.4), libsystemd-journal0:amd64 (204-5ubuntu20.8,
204-5ubuntu20.9), nautilus-data:amd64 (3.10.1-0ubuntu9.3, 3.10.1-0ubuntu9.4)
End-Date: 2014-12-01 23:21:21
Start-Date: 2014-12-01 23:21:37
Commandline: apt-get --purge autoremove
Purge: firefox-locale-nl:amd64 (33.0+build2-0ubuntu0.14.04.1)
End-Date: 2014-12-01 23:21:38
Start-Date: 2014-12-02 22:59:04
Commandline: apt-get upgrade
Upgrade: firefox-locale-en:amd64 (33.0+build2-0ubuntu0.14.10.1,
34.0+build2-0ubuntu0.14.10.2), firefox:amd64 (33.0+build2-0ubuntu0.14.10.1,
34.0+build2-0ubuntu0.14.10.2)
End-Date: 2014-12-02 22:59:10
----- END of snippet from /var/log/apt/history.log ------
Question 1: What went wrong? Was there a short-lived bug in the sysv-rc
package? Did packages not get upgraded in the right order?
Question 2: What is the impact of these extraneous symlinks on machines
with Ubuntu 14.04 and 14.10 (Upstart-based) and on those with 15.04 and
later (Systemd-based)?
In the traditional System V init world it would have been bad for
"/etc/init.d/resolvconf start" to be run in runlevel 2-5 because that
would have caused the working directories to be emptied too late in the
boot sequence. To what extent are these rc symlinks still active in
Ubuntu?
If there is a negative impact then, yes, we need to add code to the
postinst to fix up machines like mine that got broken by some earlier
upgrade.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1453185
Title:
resolvconf: updates are not enabled right after installation
Status in resolvconf package in Ubuntu:
Fix Released
Bug description:
Previously, updates were enabled in postinst script, but this enablement was
removed in a favour of upstart service
(https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/931335).
This worked fine till the switch to systemd - no postinst action to activate
resolvconf.service right after installation, one needs to reboot node in order
to get updates enabled.
Description: Ubuntu 15.04
Release: 15.04
resolvconf 1.76ubuntu1
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1453185/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
