Bug 647831 - avahi-daemon not started when it should be
Summary: avahi-daemon not started when it should be
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: avahi
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 684498 684754 689859 693094 701904 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-29 15:47 UTC by John Ellson
Modified: 2018-04-11 07:15 UTC (History)
25 users (show)

Fixed In Version: avahi-0.6.30-2.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-10 03:22:15 UTC


Attachments (Terms of Use)

Description John Ellson 2010-10-29 15:47:46 UTC
Description of problem:
avahi-daemon is not getting started at boot, even though it has been configured to do so.   The machine is unreachable from other machines until avahi-daemon is started manually from the console.

Version-Release number of selected component (if applicable):
avahi-0.6.28-2.fc15.x86_64

How reproducible:
100%   Rawhide i686 and x86_64.
Works ok in fedora 14.

Steps to Reproduce:
1. chkconfig --add avahi-daemon
2. reboot
3.
  
Actual results:
avahi-daemon not running after reboot.   No evidence of any attempt to start avahi-daemon during boot in /var/log/messages.

Starts ok after boot with manual: "service avahi-daemon start"

Expected results:
avahi-daemon should be started during boot, if configured to do so.

Additional info:
not sure if relevant, but I am running these as virtual hosts on a fedora-14, x86_64, server

Comment 2 Matěj Cepl 2010-12-02 09:00:03 UTC
100% reproduceable with

kernel-2.6.36.1-10.fc15.x86_64
avahi-0.6.28-3.fc15.x86_64
selinux-policy-3.9.10-4.fc15.noarch

Comment 3 John Ellson 2011-02-03 18:41:45 UTC
Problem still exists:

kernel-2.6.38-0.rc3.git0.1.fc15.x86_64
avahi-0.6.28-7.fc15.x86_64
selinux-policy-targeted-3.9.13-8.fc15.noarch

Comment 4 Matthias Clasen 2011-02-11 23:03:12 UTC
ccing dwalsh for possible selinux policy involvement

Comment 5 Daniel Walsh 2011-02-16 20:48:16 UTC
john could you look for AVC messages in dmesg?

dmesg | audit2allow

Nothing in Matej messages indicates an SELinux issue with avahi.  Can either you boot in permissive mode and see if it starts?

Comment 6 Matěj Cepl 2011-02-16 23:52:44 UTC
I also don't think this is an SELinux issue. Problem seems to lie in broken /sbin/chkconfig in case both /etc/init.d/ script and systemd services are present. Then chkconfig works with init.d script, but systemd uses .service file. So, when some maintainer leaves in package both init.d script and .service file chkconfig seems like working, but actually it has no effect on functioninig of the system.

I think the priorities should be other way around ... whatever subsequent run of systemd will be actually used should be changed by chkconfig, or at least chkconfig should provide big fat warning. Something like "changing running of sysvinit script, but .service file is also present" or something.

Comment 7 John Ellson 2011-02-17 16:25:31 UTC
Re: Comment 5


    [root@fc15-64 ~]# dmesg | audit2allow


    #============= vbetool_t ==============
    #!!!! This avc can be allowed using the boolean 'mmap_low_allowed'

    allow vbetool_t self:memprotect mmap_zero;
    [root@fc15-64 ~]# 



Changong to permissive mode did not fix anything.

Comment 8 Daniel Walsh 2011-02-17 19:12:48 UTC
So this is not an SELinux issue.  John you might want to remove vbetool and see if everything works (suspend/resume).  You probably do not need this package.

Comment 9 John Ellson 2011-02-17 21:24:03 UTC
I removed vbetool, thanks.  (Didn't have any effect on the avahi-daemon bug.)

Assuming Matej is on the right track, should I be using something other than chkconfig to start the service?   Should I be removing sysvinit ?

My fedora-15 and fedora-16 systems are all from upgraded fedora-14 systems, so do I have some residual junk that I need to get rid of?   Is there some doc I need to read so as to not waste your valuable time?

(I don't really care about the innards of systemd, I just want updated sys-admin instructions if I'm supposed to do something new.)

Comment 10 Lennart Poettering 2011-02-18 12:27:45 UTC
Normally, when the Avahi package got upgraded from a sysv-only to a systemd version it should have copied over whether the old init script was enabled or not.

Hmm, one question: did this break during upgrade, or is this simply something where you expected "chkconfig avahi-daemon on" to work but it had no effect?

Note that "systemctl enable avahi-daemon.service" is how you enable systemd native services.

Bill recently commited some changes I made to chkconfig to forward enabling requests to "systemctl enable". If this is not a problem related to upgrading than this fix should fix the problem.

Comment 11 John Ellson 2011-02-19 15:19:11 UTC
I created the virtual host images by:
    1. installing fc14
    2. changing the settings in etc/yum.respo.d/* to enable rawhide and disable fedora and updates.
    3. doing a "yum update"

As I recall, avahi-daemon was not enabled before, and is not enabled by default in rawhide, so i think I enabled it after upgrading to rawhide by using "chkconfig'

So, as I understand it, I was correct in expecting "chkconfig" to work, but it wasn't ? 


I don't see the chkconfig update yet, but I can confirm that "systemctl enable avahi-daemon.service" followed by a reboot has fixed the problem.

Comment 12 Will Woods 2011-03-08 20:43:10 UTC
Fedora 15 Alpha installs are starting with avahi disabled:
# systemctl status avahi-daemon.service
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
	  Loaded: loaded (/lib/systemd/system/avahi-daemon.service)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/avahi-daemon.service
# systemctl is-enabled avahi-daemon.service || echo avahi disabled
avahi disabled


F14 avahi %post does:
# Run avahi-daemon by default:
  /sbin/chkconfig --add avahi-daemon >/dev/null 2>&1 || :
  /usr/bin/systemd-install --realize=minimal enable avahi-daemon.service >/dev/null 2>&1 || :

F15 avahi %post does just:
  /sbin/chkconfig --add avahi-daemon >/dev/null 2>&1 || :

chkconfig only touches systemd if you give it 'on' or 'off', so I think you need to add:
  /sbin/chkconfig avahi-daemon on >/dev/null 2>&1 || :

if we still want the service to be on-by-default. Or maybe there's some magic LSB header parsing in systemd that's not working right?

Comment 13 Lennart Poettering 2011-03-09 00:41:49 UTC
The service is no longer on by default, as it is open to the network. If we want it enabled by default we probably should do so in some script after installation.

Comment 14 Matěj Cepl 2011-03-09 16:10:16 UTC
(In reply to comment #13)
> The service is no longer on by default, as it is open to the network. If we
> want it enabled by default we probably should do so in some script after
> installation.

Except it kind of defeats the purpose of Avahi, doesn't it? Do we expect your mom (or dad to be PC ;)) to like that he has to run su -c 'chkconfig avahi-daemon on' ?

Comment 15 Daniel Walsh 2011-03-09 22:06:31 UTC
I don't want my Dad running avahi.  :^)

Comment 16 Lennart Poettering 2011-03-15 01:59:49 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > The service is no longer on by default, as it is open to the network. If we
> > want it enabled by default we probably should do so in some script after
> > installation.
> 
> Except it kind of defeats the purpose of Avahi, doesn't it? Do we expect your
> mom (or dad to be PC ;)) to like that he has to run su -c 'chkconfig
> avahi-daemon on' ?

No, but the installation program should have enabled it by default.

My dad runs Avahi! ;-)

Comment 17 Tim Waugh 2011-03-29 15:02:38 UTC
Avahi is needed for network printer discovery.

Comment 18 Brian Pepple 2011-03-30 00:05:51 UTC
It's also needed for telepathy-salut ("People Nearby" account) in Empathy which is created during account set-up.  Without avahi enabled the account throbber will continuously spin unless the salut account is disabled.

Comment 19 Brian Pepple 2011-03-30 00:06:23 UTC
*** Bug 684498 has been marked as a duplicate of this bug. ***

Comment 20 Lennart Poettering 2011-03-31 12:18:30 UTC
Hmm, so, I'd like to see avahi enabled by anaconda or so, instead of in the rpm package itself. That way people who install fedora get it enabled by default, but those who install the package on an existing system don't. I think that behaviour would be best.

Reassigning to anaconda.

Anaconda folks, can you add a "systemctl enable avahi-daemon.service" call somewhere when installing Fedora to HDD?

Comment 21 Brian Pepple 2011-03-31 14:57:32 UTC
(In reply to comment #20)
> Hmm, so, I'd like to see avahi enabled by anaconda or so, instead of in the rpm
> package itself. That way people who install fedora get it enabled by default,
> but those who install the package on an existing system don't. I think that
> behaviour would be best.
> 
> Reassigning to anaconda.
> 
> Anaconda folks, can you add a "systemctl enable avahi-daemon.service" call
> somewhere when installing Fedora to HDD?

From a user usability standpoint, it would be nice to also poke a hole in the firewall for port 5353 at the same time, so avahi support works out of the box.

Comment 22 Tim Waugh 2011-03-31 15:39:42 UTC
Perhaps that's something that ought to be handled at run-time using firewalld?

Comment 23 Brian Pepple 2011-03-31 15:46:46 UTC
(In reply to comment #22)
> Perhaps that's something that ought to be handled at run-time using firewalld?

Firewalld isn't installed by default is it? I think once it is, that would make sense.

Comment 24 Will Woods 2011-03-31 15:54:19 UTC
I'd really like to avoid making the installer responsible for setting up the default services. I don't want to put that code outside the reach of the people packaging the services, and I *really* don't want the installer team to be politically responsible for the decision to enable or disable a service.

What about this: it's possible that a package's %post script could detect whether it's being run during initial system install. In that case, you could have avahi enable itself *only* during system instalation - it could even run 'lokkit --service=mdns' to properly configure the firewall for avahi (open port 5353 and enable v4/v6 multicast). Would that work?

(I personally want avahi on/enabled by default, but I understand that there are plenty of people who would vehemently disagree, and for not-wholly-unsound reasons.)

As a side note: systemd won't be running during installation, so I'm not sure if doing 'systemctl enable ..' in anaconda would even work. It might make sense to have a kickstart 'systemctl' command which would correctly enable/disable services on the target system - but that's a different bug entirely, and it still wouldn't actually solve the problem here.

Comment 25 Matěj Cepl 2011-03-31 18:21:48 UTC
(In reply to comment #22)
> Perhaps that's something that ought to be handled at run-time using firewalld?

firewalld for normal users is a F16 Feature.

Comment 26 Lennart Poettering 2011-04-02 02:08:37 UTC
*** Bug 689859 has been marked as a duplicate of this bug. ***

Comment 27 Lennart Poettering 2011-04-02 02:12:27 UTC
(In reply to comment #24)
> I'd really like to avoid making the installer responsible for setting up the
> default services. I don't want to put that code outside the reach of the people
> packaging the services, and I *really* don't want the installer team to be
> politically responsible for the decision to enable or disable a service.
> 
> What about this: it's possible that a package's %post script could detect
> whether it's being run during initial system install. In that case, you could
> have avahi enable itself *only* during system instalation - it could even run
> 'lokkit --service=mdns' to properly configure the firewall for avahi (open port
> 5353 and enable v4/v6 multicast). Would that work?

How would we detect this?

I am not entirely sure this is really the ideal solution, as I think this should be in some installation profile thing, rather than in the packages. After all, on a desktop spin install we might want it installed and on, and on a server spin we might want it installed and off.

However, given that we apparently don't have such a profile thing, what you suggest is a workable solution.

> As a side note: systemd won't be running during installation, so I'm not sure
> if doing 'systemctl enable ..' in anaconda would even work. It might make sense
> to have a kickstart 'systemctl' command which would correctly enable/disable
> services on the target system - but that's a different bug entirely, and it
> still wouldn't actually solve the problem here.

"systemctl enable" detects when it is run in a chroot, and if so will never try to talk to systemd, and just enable the unit files in the FS and that's that.

So, if anaconda calls systemctl in a chroot things should be jolly.

Comment 28 Brian Pepple 2011-04-02 16:33:43 UTC
*** Bug 693094 has been marked as a duplicate of this bug. ***

Comment 29 Lennart Poettering 2011-04-03 22:02:22 UTC
*** Bug 684754 has been marked as a duplicate of this bug. ***

Comment 30 Will Woods 2011-04-06 16:08:50 UTC
I agree that installation profiles would be a really clean way to handle this type of thing. We should revisit that idea soon.

Martin Sivak had a really good idea: what if you created a package (something like 'fedora-profile-desktop') that had:

%post
systemctl enable avahi-daemon.service
lokkit ----service=mdns
[etc.]

and added that to the gnome-desktop comps group as a default package?

(For F16 and beyond: if we had profile packages like this for -server, -workstation, etc. we could easily put them in their own comps group, and present those in the anaconda UI. That would give us installation profiles, controlled outside the anaconda team. Hooray!)

Comment 31 Lennart Poettering 2011-04-06 18:47:28 UTC
Hmm, I am not sure I want to be the one championing this as that wouldn't be just a small change and probably requires more buyin from other people. But sounds like a really good idea for F16.

Hmm, in #24 you mentioned packages can detect if they are installed during system installation or later on. How would that work? That might be a quick fix suitable for F15.

(Only way I could think of would be to detect a chroot env, but that'd be a bit ugly)

Comment 32 Will Woods 2011-04-07 14:57:35 UTC
There's no well-defined way to check whether you're in anaconda's chroot. You could do:
  [ `pidof -x anaconda` ] && ...
but I strongly discourage using that to solve this problem.

The Real Solution for opening the ports is firewalld, but that's not here yet.

The Real Solution for deciding which services etc. get enabled by default in a new install is probably system profiles. And the anaconda team seems to agree that system-profile (meta|speudo)packages are the best way to tackle this.

So I'd suggest creating a fedora-profile-desktop (or similar) package to handle this problem.. BUT. 

I just noticed this: 
https://fedoraproject.org/wiki/Starting_services_by_default

As of 23 March 2011 avahi is on the official FESCo list of services that may start by default.. so it's perfectly OK for avahi to enable itself and open the ports when it gets installed.

Comment 33 Lennart Poettering 2011-05-02 23:21:18 UTC
I will now upload a new version which enables avahi by default again.

Comment 34 Lennart Poettering 2011-05-02 23:23:16 UTC
This will enable avahi only for new installs. People upgrading from an existing F15 version need to enable it manually with "systemctl enable avahi-daemon.service"

Comment 35 Fedora Update System 2011-05-02 23:23:41 UTC
avahi-0.6.30-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/avahi-0.6.30-2.fc15

Comment 36 Fedora Update System 2011-05-03 04:27:03 UTC
Package avahi-0.6.30-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing avahi-0.6.30-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/avahi-0.6.30-2.fc15
then log in and leave karma (feedback).

Comment 37 Jiri Popelka 2011-05-04 09:35:02 UTC
*** Bug 701904 has been marked as a duplicate of this bug. ***

Comment 38 Fedora Update System 2011-05-10 03:22:05 UTC
avahi-0.6.30-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 39 Jean-François Fortin Tam 2011-05-13 01:31:04 UTC
I still see this problem with 0.6.30-3.fc15. Could you reopen this bug?

Comment 40 RavanH 2011-05-17 21:31:41 UTC
did you do "su -c 'systemctl enable avahi-daemon.service'" after the upgrade?

Comment 41 Jean-François Fortin Tam 2011-05-21 04:02:02 UTC
RavanH: no I didn't, running that command seems to have fixed it. 

Should I also run such a command for other services (such as sshd and cherokee) that still don't start? Will users installing from the final release have to run this command?

Comment 42 RavanH 2011-05-21 09:51:45 UTC
as i understand it, an install from final should not need the command, just for those that installed previously to the fix... no idea about other services.


Note You need to log in before you can comment on or make changes to this bug.