Failed to restart avahi-dnsconfd.service

For a long while whenever I have done a software upgrade, things come to a shuddering halt, with a plethora of error messages, starting with “Failed to restart avahi-dnsconfd.service” as given in the subject heading. The software upgrade terminates with a little pop-up window saying that the process could not be completed.

My laptop seems to continue to function adequately, but something is clearly not quite right and I’d like to fix it. However I have no idea where to start. Can someone point me in the right direction?

This is mainly of concern to me because I would like to upgrade my installation of R. When I do

sudo apt-get install r-base

(a) I get told “r-base is already the newest version (3.5.2-1bionic).” (although when I start R it is apparent that I am running version 3.5.1(

(b) I get asked if I want to continue (anyway); I answer “y” and then get the avahi.dnsconfd.service error and everything seems to come to a stop.

I would really be grateful for some help with this problem.

I have no idea what further information would be useful but am of course happy to provide (do my best to provide) any such information that I am asked for.

I am running the Mate Desktop Environement 1.20.1 under Ubuntu 18.04.

It appears that you don’t have a fresh install so you may have some obsolete or unsupported packages. To make it easier to post details, I suggest sticking to command-line tools in a terminal.

It may be useful to determine which package installed R-3.5.1. The apt-file command helps with this. You can use “which R” to find the full path
of the installed version of R. Typically this is “/usr/bin/R” (but could differ, e.g., if you installed R from source it might be “/usr/local/bin/R”). Then install “apt-file” and run, e.g., “apt-file search /usr/bin/R”.

The “aptitude” package manager has a section for obsolete packages and is text based so it is easy to past information into a forum post. If you don’t already have it, I suggest you install “aptitude” and check for obsolete packages. In “aptitude”,
enter “u” (lower-case) to update the list of available packages and “U” to select
packages to be updated. Enter “g” to list the packages to be installed, and “g”
again to do the install. If there are conflicts, aptitude will give you some options to
keep or remove packages to resolve the conflict.

If you have been using PPA’s from older Ubuntu versions you should consider removing any that you no longer need. If you use a lot of PPA’s there are PPA managers like Y-PPA-Manager or Aptik.

January 27

It appears that you don’t have a fresh install so you may have some
obsolete or unsupported packages. To make it easier to post details, I
suggest sticking to command-line tools in a terminal.

I almost always do stick to command-line tools. I am very
uncomfortable with any point-and-click interface.

It may be useful to determine which package installed R-3.5.1.

I installed R-3.5.1 from source. But I have been advised not to do
such "from source" installations, and am trying to switch over to using
the "sudo apt-get" paradigm. But have, as I have described, encountered
problems.

The apt-file command helps with this. You can use “which R” to find the full
path
of the installed version of R. Typically this is “/usr/bin/R” (but could
differ, e.g., if you installed R from source it might be
“/usr/local/bin/R”). Then install “apt-file” and run, e.g., “apt-file
search /usr/bin/R”.

The command "which R" produces "/usr/bin/R", as expected.

The “aptitude” package manager has a section for obsolete packages and
is text based so it is easy to past information into a forum post. If
you don’t already have it, I suggest you install “aptitude” and check
for obsolete packages. In “aptitude”,
enter “u” (lower-case) to update the list of available packages and “U”
to select
packages to be updated. Enter “g” to list the packages to be installed,
and “g”
again to do the install. If there are conflicts, aptitude will give you
some options to
keep or remove packages to resolve the conflict.

I did some stuff with aptitude (I had it installed already) but I'm not
really sure what I'm doing and found the interface to be mysterious.

If you have been using PPA’s from older Ubuntu versions you should
consider removing any that you no longer need. If you use a lot of PPA’s
there are PPA managers like Y-PPA-Manager or Aptik.

I just did a "sudo apt autoremove" (as prompted by "sudo apt-get
upgrade") and this seemed to remove a lot of rubbish. But the
avahi-dnsconfd.service still hung around.

Please note that the problem is, as far I can understand things, not
really with R, as such, but with the avahi-dnsconfd.service.

Following your advice I started aptitude and it seems to indicate that
avahi-dnsconfd is "partially installed". (It appears to be the only
such package.)

It is still not clear to me what to do about it. As indicated above,
autoremove does not get rid of it. I thought perhaps that explicitly
removing this package (and then (re-) installing it) might work, but I
am hesitant to try it and not sure of the syntax. Maybe something like:

sudo apt remove avahi-dnsconfd
sudo apt-get install avahi-dnsconfd

Would that be right? Would it work? Is it dangerous to try it? If this
isn't the right way to go, can you (or someone) suggest what would be
right and would work?

Thanks.

cheers,

Rolf Turner

P.S. I have attached a screenshot of the aptitude window that shows up
when I started aptitude and typed "g".

R. T.

Continuing the discussion from Failed to restart avahi-dnsconfd.service:

After a bit of (more) Googling around, I found the site

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768620

which contained the lines:

Dear Maintainer,

to resolve this mess manually these steps are sufficient:

systemctl disable avahi-daemon
apt-get --reinstall install avahi-daemon
systemctl enable avahi-daemon

after that i can reinstall the packages without any problems

I then tried

sudo systemctl disable avahi-daemon

and got (amongst other things) the message

/etc/systemd/system/avahi-daemon.service is masked, ignoring.

More Googling about the "masked" business seemed to reveal that masking is effected by making a symbolic link from the file in question to /dev/null, and if this is the case then unmasking can be accomplished by removing the symbolic link.

I did

cd /etc/systemd/system
ls -l avahi-daemon.service

and indeed got

lrwxrwxrwx 1 root root 9 Aug 20 16:05 avahi-daemon.service -> /dev/null

So I then did:

sudo rm avahi-daemon.service
sudo systemctl disable avahi-daemon

and this time it seemed to run OK.

I then tried "sudo apt-get upgrade" again. The first time I got the slightly ominous:

Setting up avahi-dnsconfd (0.7-3.1ubuntu1.1) ...
W: APT had planned for dpkg to do more than it reported back (0 vs 4).
Affected packages: avahi-dnsconfd:amd64

But a second iteration seemed to produce a clean bill of health.

So I think this problem can be considered to be solved.

I see you have resolved the avahi-dnsconfd issue. Moving on, it is not a good idea to do installs from source to the location used by distro packages. If you change your mind it can be very hard to undo such installs as packages typically sprinkle files in lib, man, doc, bin and other locations. Package managers differ in how they respond when they try to install a file that already exists – they may refuse to install, rename existing files, install new files with a modified name, or just overwrite existing files, but won’t do anything to files installed in a location that
isn’t used by the packaged version. For Debian-based systems like Ubuntu,

sudo apt-get -o Dpkg::Options::="--force-overwrite" install ...

should overwrite files installed outside the package manager.

R is better than many about spreading files around /usr and /etc. Also, moving from locally installed R-3.5.1 to distro R-3.5.2 may not
break site library packages you installed from source (there could be issues with fortran and C++ when mixing binaries built with different runtime libraries, e.g.,
if your local install was done with a newer gcc suite than was used for distro packages).

The “checkinstall” tool could be used to reinstall R-3.5.1 while creating a “.deb” package that can be used to uninstall R-3.5.1, per [if I build a package from source how can I uninstall or remove completely?](https://askubuntu.com/questions/87111/if-i-build-a-package-from-source-how-can-i-uninstall-or-remove-completely].