resolvconf: updates are not enabled right after installation

FTR, this is unrelated to pid1. The issue is that older versions called dh_installinit which added the invoke-rc.d call to postinst. Current version calls "dh_installinit --no-start", so the update wouldn't happen right after package installation under any init system.

This bug was fixed in the package resolvconf - 1.76.1ubuntu2

---------------
resolvconf (1.76.1ubuntu2) wily; urgency=medium

  * debian/postinst: Put back calling resolvconf during configuration, to
    immediately apply it after package installation. This drops the Ubuntu
    delta introduced in LP #931335, which got broken because the postinst now
    does not call invoke-rc.d at all. (LP: #1453185)

 -- Martin Pitt <email address hidden> Wed, 27 May 2015 10:23:18 +0200

In the Debian postinst there is a case clause at the end whose purpose is to enable updates. In Debian this is done by means of a trigger.

----------------resolvconf 1.77 ----------------
[...]
case "$1" in
  reconfigure)
                resolvconf --enable-updates
        ;;
  configure)
        if [ "$DEBCONF_RECONFIGURE" = 1 ] ; then
                resolvconf --enable-updates
        else
                # Trigger self to enable updates later
                dpkg-trigger --no-await resolvconf-enable-updates || resolvconf --enable-updates
        fi
        ;;
  triggered)
        # Runs after this and other packages have been configured
        for trggr in $2 ; do
                case "$trggr" in
                  resolvconf-enable-updates)
                        resolvconf --enable-updates
                        break
                        ;;
                esac
        done
        ;;
[...]
--------------------------------

The Ubuntu postinst omits that whole clause. In the Upstart era updates were enabled by means of an "invoke-rc.d resolvconf start" at the end of the file, inserted by dh_installinit called without "--no-start".

--------------- resolvconf 1.69ubuntu1 -----------------
[...]
# Automatically added by dh_installinit
if [ -x "/etc/init.d/resolvconf" ]; then
        if [ ! -e "/etc/init/resolvconf.conf" ]; then
                update-rc.d resolvconf defaults >/dev/null
        fi
        invoke-rc.d resolvconf start || exit $?
fi
# End automatically added section
# Automatically added by dh_installinit
update-rc.d -f resolvconf remove >/dev/null || exit $?
# End automatically added section

exit 0
--------------------------------

I would suggest that Ubuntu resolvconf's postinst simply add a clause at the end, like the one in Debian, which runs "resolvconf --enable-updates" on configure. This will minimize the diff with the Debian postinst.

For background on the sorts of problems that can arise when changes are made to the postinst that haven't been fully thought through, see bug #1085862.

@Thomas: I found it best to simply drop that part of our delta, which both fixes this bug again and makes maintenance easier.

@Martin: My previous comment raced with your release of 1.76.1ubuntu2. Looks good.

@Martin: Ubuntu resolvconf 1.76.1ubuntu2 includes the trigger-sending and trigger-processing section at the end of the postinst but fails to include the debian/triggers file from Debian. Without this file the resolvconf package doesn't register an interest in the trigger resolvconf-enable-updates.

I'd like to comment on the remaining differences between Debian resolvconf and Ubuntu resolvconf.

Besides the extensive source-textual differences arising from Debian's use of /etc/resolvconf/run versus Ubuntu's direct use of /run/resolvconf, I see only three substantial differences.

1. The omission of debian/triggers in Ubuntu

As mentioned previously (comment 6) I am guessing that this is an oversight.

2. Debconf question resolvconf/link-tail-to-original defaulting to true in Ubuntu versus false in Debian

This only makes a difference, and the answer "true" is only useful, when installing resolvconf on a resolvconfless system that already had a handcrafted /etc/resolv.conf file and the admin doesn't want to take the time right away to move the "nameserver" lines from /etc/resolvconf/resolv.conf.d/original to the appropriate place in /etc/network/interfaces. This use case seems very far from the typical circumstances on an Ubuntu system where resolvconf is part of the base system. I'd say drop this difference unless there is a known good reason to preserve it. If there is a reason then please document it somewhere, e.g., in debian/NOTES.

3. dhclient-enter-hooks.d/resolvconf undefining make_resolv_conf() only if /etc/resolv.conf is a symbolic link, in contrast with Debian resolvconf where that script undefines make_resolv_conf() even if /etc/resolv.conf is not a symbolic link.

See bug #1385010 for discussion. My position is that this diff should be dropped. It's a feature of resolvconf that when you install it, other programs don't engage in their legacy behavior of overwriting /etc/resolv.conf. With the diff in question here, Ubuntu reactivates dhclient's legacy behavior (which Debian resolvconf had deactivated) of overwriting /etc/resolv.conf if the latter is not a symbolic link. Some people might want that; others do not (bug #1385010). My view is that people who want the legacy behavior should de-install resolvconf to obtain it. The resolvconf package and the symbolic link at /etc/resolv.conf are on the system by default, so the diff in question has no effect on a typical Ubuntu system. So twhat reason is there to depart from Debian in this respect?

Perhaps it's a concession to the expectations of admins who are more familiar with other distros.

If there is a reason then whatever the reason is, please document it in a comment.

Cheers!

Thanks Thomas for the review! I cleaned up the three issues you mentioned.

Out of interest, do you plan to keep /etc/resolvconf/run in Debian? To me this has always appeared to be a transitional thing in Debian, as going through that indirection is a bit confusing and also cluttering of /etc.

+ - debian/postinst: Make /etc/resolv.conf a relative symlink so that it
+ works when setting up chroots.

This also seems useful in Debian?

The indirection via /etc/resolvconf/run dates from the era before /run/. I introduced resolvconf in 2003 as part of a larger effort to make it possible to run Debian with a read-only root filesystem[1] but the project to introduce the /run/ tmpfs into Debian base failed due to lack of consensus about the need for it[2][3] and disagreement about what to call it[4]. (The references are just a few examples out of several long exhausting threads.) Not being even a Debian Developer myself, I shelved the controversial /run project[5] and carried on developing resolvconf which still needed some location for its state files, preferably on a tmpfs. The best available location at first was /dev/shm/. Later /lib/init/rw/ was introduced and I converted resolvconf to use that by default. I knew that /dev/shm/ was a controversial and probably temporary solution and I also wanted to accomodate people who didn't want to use any tmpfs at all, so I made the ultimate location of the state directory configurable by means of the symbolic link /etc/resolvconf/run. When /run/ became part of the Debian base system in 2011[6] the need for this configurability disappeared. Nowadays there is no good reason not to keep the files under /run/resolvconf/. Accordingly, debian/NOTES already includes the following TODO list.

---------------------------
                     MAINTAINER NOTES
                      for resolvconf
TODO
----
* File bug reports against all packages containing suppliers of nameserver
  information, asking each to add a resolvconf packaging-event hook script.
  Still to be submitted: dhcpcd5, pump, udhcpc
* In Jessie+1, drop the use of /etc/resolvconf/run; use /run/resolvconf directly.
--------------------------

When I have a few free hours I will take care of the second item. Writing maintainer script code to transition existing resolvconf-using machines to the new setup without breaking anything is not entirely trivial. :)

[1]https://lists.debian.org/debian-devel/2003/04/msg02057.html
[2]https://lists.debian.org/debian-devel/2003/05/msg00280.html
[3]https://lists.debian.org/debian-devel/2003/05/msg00247.html
[4]https://lists.debian.org/debian-devel/2003/04/msg00158.html
[5]https://lists.debian.org/debian-devel/2003/05/msg01479.html
[6]https://wiki.debian.org/ReleaseGoals/RunDirectory

Yep, I see that debian/triggers is present in 1.77ubuntu1, and when I install the package I see the report of the trigger being processed. Thx! P.S. Is there something we should do to silence those insserv warnings?

$ sudo dpkg -i resolvconf_1.77ubuntu1_all.deb
(Reading database ... 282465 files and directories currently installed.)
Preparing to unpack resolvconf_1.77ubuntu1_all.deb ...
Unpacking resolvconf (1.77ubuntu1) over (1.76.1ubuntu2) ...
Setting up resolvconf (1.77ubuntu1) ...
Installing new version of config file /etc/dhcp/dhclient-enter-hooks.d/resolvconf ...
Installing new version of config file /etc/resolvconf/interface-order ...
insserv: warning: current start runlevel(s) (2 3 4 5) of script `resolvconf' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (0 1 6) of script `resolvconf' overrides LSB defaults (0 6).
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (219-7ubuntu5) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for resolvconf (1.77ubuntu1) ...
insserv: warning: current start runlevel(s) (2 3 4 5) of script `resolvconf' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (0 1 6) of script `resolvconf' overrides LSB defaults (0 6).

Hey THomas,

Thomas Hood [2015-06-01 8:35 -0000]:
> Is there something we should do to silence those insserv warnings?
> insserv: warning: current start runlevel(s) (2 3 4 5) of script `resolvconf' overrides LSB defaults (S).
> insserv: warning: current stop runlevel(s) (0 1 6) of script `resolvconf' overrides LSB defaults (0 6).

It looks like your installation still has rc[2-5].d/ start symlinks
for resolvconf? insserv won't override them on upgrade. So perhaps an
older version of insserv used to call update-rc.d with specific
runlevels and priorities, that was cleaned up later to use LSB
headers, but they didn't match? For that case you need a postinst
snippet to correct the links before the (debhelper generated)
update-rc.d call, if you care. However, this is of course a bit
brittle to get right in all corner cases..

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+...

Continuing with my investigation of how a default symlink field got created for resolvconf on my machine... (What I am calling a 'default symlink field' is the set of symlinks /etc/rc[1-5].d/S??resolvconf -> ../init.d/resolvconf as would be created by "update-rc.d resolvconf defaults" with update-rc.d from older sysv-rc packages.)

Debian
------
Support for "start" and "stop" commands to update-rc.d was dropped in sysvinit 2.88dsf-42 which was released 13 July 2013. This is what led to Debian bug report #718232 which led to the change to resolvconf mentioned above, which saw the light of day in resolvconf 1.75 released in May 2014. Unfortunately, this resolvconf release didn't constrain the version of sysv-rc with which it could be installed. It should have declared something like Breaks: sysv-rc (<< 2.88dsf-42). This is a bug in Debian resolvconf. Jessie includes sysv-rc 2.88dsf-59 but the previous release Wheezy contains only 2.88dsf-41, so on upgrade from Wheezy to Jessie it is possible that resolvconf upgrades first and its postinst executes update-rc.d from the previous release. I imagine that this could create a default symlink field for resolvconf.

Ubuntu
------
The start-and-stopless version of sysvinit appeared in Ubuntu only in 15.04. But Ubuntu resolvconf postinst was doing "update-rc.d resolvconf defaults" even earlier than May 2014 as evidenced by insserv warnings in my logs. Checking old versions of Ubuntu resolvconf I see that the following versions did "update-rc.d resolvconf defaults".

* 1.77ubuntu1 YES
* 1.76ubuntu1 in Vivid 15.04 YES
* 1.69ubuntu4 in Utopic 14.10 YES
* 1.69ubuntu1.1 in Trusty-updates YES
* 1.69ubuntu1 in Trusty 14.04 YES
* 1.63ubuntu16 in Precise-updates NO
* 1.63ubuntu11 in Precise NO
* 1.45ubuntu1 in Lucid NO

I think that this means that a LOT of Ubuntu machines have default symlink fields for resolvconf. Which is wrong and bad unless these symlinks can have no effect, in which case it's merely ugly. Resolvconf has long had an Upstart job configuration file and now has a systemd unit file, so I hope that this means that the bogus symlinks could never have had any effect.

What do you think, Martin? Was there in Trusty or later an option to run Ubuntu with sysvinit instead of Upstart, or do the rc symlinks have side effects even when Upstart is used?

On Mon, Jun 01, 2015 at 07:06:06PM -0000, Thomas Hood wrote:
> Was there in Trusty or later an option to run Ubuntu with sysvinit instead
> of Upstart,

No. sysvinit is not supported on any version of Ubuntu since karmic.

> or do the rc symlinks have side effects even when Upstart is used?

Also no.