Hi David,

Which avahi related packages are installed on your system? Do you know how this problem can be reproduced?

Regards,

-- Shlomi Fish

libavahi-core7-0.6.31-15.mga5
libavahi-common3-0.6.31-15.mga5
avahi-0.6.31-15.mga5
libavahi-gobject0-0.6.31-15.mga5
libavahi-glib1-0.6.31-15.mga5
libavahi-client3-0.6.31-15.mga5

For reproducing, I didn't do anything special.  I just booted it and logged into KDE.  I'm not sure why it's trying to activate the Avahi service.  I do have a printer configured on the machine.

(In reply to David Walser from comment #2)
> libavahi-core7-0.6.31-15.mga5
> libavahi-common3-0.6.31-15.mga5
> avahi-0.6.31-15.mga5
> libavahi-gobject0-0.6.31-15.mga5
> libavahi-glib1-0.6.31-15.mga5
> libavahi-client3-0.6.31-15.mga5
> 
> For reproducing, I didn't do anything special.  I just booted it and logged
> into KDE.  I'm not sure why it's trying to activate the Avahi service.  I do
> have a printer configured on the machine.

Are you using a display manager (KDM, GDM, etc.)? If so, which one? Does it happen when logging in to a new UNIX user account?

I'm using KDM.  These messages appeared twice.  Once was right after colord.service started (which itself has some messages about the printer, so it might be related).  This is even if nobody logs in.  The other time was after logging into KDE, right after org.kde.powerdevil.backlighthelper (also a dbus-activated service) starts.

(In reply to David Walser from comment #0)
> In Cauldron, I see these messages in the journal:
> dbus[712]: [system] Activating via systemd: service
> name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
> dbus[712]: [system] Activation via systemd failed for unit
> 'dbus-org.freedesktop.Avahi.service': Unit
> dbus-org.freedesktop.Avahi.service failed to load: No such file or directory.
> 
> 
> For other similar bus-activated services, what they say in the unit='' part
> usually corresponds to a service file in /lib/systemd/system.  In this case,
> the file it's looking for is
> /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service

Are you sure? I suspect not as the name is "dbus-org.freedesktop.Avahi.service" which is fairly common for dbus activated system services.

Looking at /usr/lib/systemd/system/avahi-daemon.service this is indeed a unit Alias named provided in the [Install] section and also corresponds to the SystemdService= in the above dbus .service file.

Can I ask, is avahi enabled? (systemctl status avahi-daemon). If not, then it's Alias'ed name which is used for dbus activation will not exist and thus dbus activation will fail. This is pretty much expected behaviour. If the admin wants to disable it, they can (and it won't be unexpectedly started again via dbus activation).

In this case, avahi is started in two ways, once as part of a normal boot (as part of multi-user.target) and secondly via dbus (in this case, it's possible that dbus activation kicks in *before* systemd gets around to starting it, so this is still a useful feature, even if 99999/1000000 times, it will already be running before a dbus client tries to use it).

So I think the way to fix this one is to simply enable avahi.

(In reply to Colin Guthrie from comment #5)
> (In reply to David Walser from comment #0)
> > For other similar bus-activated services, what they say in the unit='' part
> > usually corresponds to a service file in /lib/systemd/system.  In this case,
> > the file it's looking for is
> > /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service
> 
> Are you sure? I suspect not as the name is
> "dbus-org.freedesktop.Avahi.service" which is fairly common for dbus
> activated system services.

I'm not sure what you mean by that.  The file name I gave is the actual name of the file in the avahi package.  If it's misnamed, please advise so that this can be fixed in the package.

> Looking at /usr/lib/systemd/system/avahi-daemon.service this is indeed a
> unit Alias named provided in the [Install] section and also corresponds to
> the SystemdService= in the above dbus .service file.
> 
> Can I ask, is avahi enabled? (systemctl status avahi-daemon). If not, then
> it's Alias'ed name which is used for dbus activation will not exist and thus
> dbus activation will fail. This is pretty much expected behaviour. If the
> admin wants to disable it, they can (and it won't be unexpectedly started
> again via dbus activation).

avahi-daemon.service is disabled.

If this is expected behavior, the log messages could be a lot more helpful.  As it is, it looks like a bug.

> In this case, avahi is started in two ways, once as part of a normal boot
> (as part of multi-user.target) and secondly via dbus (in this case, it's
> possible that dbus activation kicks in *before* systemd gets around to
> starting it, so this is still a useful feature, even if 99999/1000000 times,
> it will already be running before a dbus client tries to use it).
> 
> So I think the way to fix this one is to simply enable avahi.

So maybe this is not a bug, just a misleading log message?

(In reply to David Walser from comment #6)
> (In reply to Colin Guthrie from comment #5)
> > (In reply to David Walser from comment #0)
> > > For other similar bus-activated services, what they say in the unit='' part
> > > usually corresponds to a service file in /lib/systemd/system.  In this case,
> > > the file it's looking for is
> > > /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service
> > 
> > Are you sure? I suspect not as the name is
> > "dbus-org.freedesktop.Avahi.service" which is fairly common for dbus
> > activated system services.
> 
> I'm not sure what you mean by that.  The file name I gave is the actual name
> of the file in the avahi package.  If it's misnamed, please advise so that
> this can be fixed in the package.

You said: "In this case, the file it's looking for is /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service" in reference to the error message. I think this is incorrect as I think the log message is referring to the field SystemdService= in the file you referred to (/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service)


> > Looking at /usr/lib/systemd/system/avahi-daemon.service this is indeed a
> > unit Alias named provided in the [Install] section and also corresponds to
> > the SystemdService= in the above dbus .service file.
> > 
> > Can I ask, is avahi enabled? (systemctl status avahi-daemon). If not, then
> > it's Alias'ed name which is used for dbus activation will not exist and thus
> > dbus activation will fail. This is pretty much expected behaviour. If the
> > admin wants to disable it, they can (and it won't be unexpectedly started
> > again via dbus activation).
> 
> avahi-daemon.service is disabled.
> 
> If this is expected behavior, the log messages could be a lot more helpful. 
> As it is, it looks like a bug.

If the service is disable, dbus will not activate it. I tend to agree that it's not as helpful as it could be!

> > In this case, avahi is started in two ways, once as part of a normal boot
> > (as part of multi-user.target) and secondly via dbus (in this case, it's
> > possible that dbus activation kicks in *before* systemd gets around to
> > starting it, so this is still a useful feature, even if 99999/1000000 times,
> > it will already be running before a dbus client tries to use it).
> > 
> > So I think the way to fix this one is to simply enable avahi.
> 
> So maybe this is not a bug, just a misleading log message?

If enabling avahi fixes everything then I'd say that's correct.

I agree the log messages are horrible. It's kinda tricky tho', as the way it's working here is it's relying on an alias to trigger it. If the *dbus* .service file referred to the systemd unit as "avahi-daemon.service" (rather than the alias name dbus-org.freedesktop.Avahi.service) then it would activate it regardless as to whether or not the administrator enabled avahi or not. This might be confusing for an admin to find a service running that was not enabled. This is why this alias scheme is used. Until the unit is enabled, the alias does not exist (it's in it's [Install] section) and thus as far as activation goes, the unit does not exist at all. This results in the confusing error message. Because of this layer of indirection (via the alias) I can see that fixing the error message to be more user friendly might be a bit tricky :(

(In reply to Colin Guthrie from comment #7)
> You said: "In this case, the file it's looking for is
> /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service" in
> reference to the error message. I think this is incorrect as I think the log
> message is referring to the field SystemdService= in the file you referred
> to (/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service)

So, I think what you're telling me is that I was mistaken in thinking that it's looking for that file (which isn't a surprise, since I thought service files should be in /lib/systemd/system and not /usr/share/dbus-1/system-services), when it's actually looking for /lib/systemd/system/avahi-daemon.service, which contains Alias=dbus-org.freedesktop.Avahi.service in its Install section.

> I agree the log messages are horrible. It's kinda tricky tho', as the way
> it's working here is it's relying on an alias to trigger it. If the *dbus*
> .service file referred to the systemd unit as "avahi-daemon.service" (rather
> than the alias name dbus-org.freedesktop.Avahi.service) then it would
> activate it regardless as to whether or not the administrator enabled avahi
> or not. This might be confusing for an admin to find a service running that
> was not enabled. This is why this alias scheme is used. Until the unit is
> enabled, the alias does not exist (it's in it's [Install] section) and thus
> as far as activation goes, the unit does not exist at all. This results in
> the confusing error message. Because of this layer of indirection (via the
> alias) I can see that fixing the error message to be more user friendly
> might be a bit tricky :(

So, when it goes looking for dbus-org.freedesktop.Avahi.service, it doesn't know that the reason it can't find it is that it's an alias to a disabled service, so it can't easily print a more helpful error message.  I guess that makes sense.

What doesn't make as much sense (as you already mentioned earlier) is having a scheme where it wants to dbus activate a service that's already enabled, in which case it should already be running anyway, and that's the only case in which it works.  I'm not sure I see the point of dbus activating it at all then :o)

I'm not sure that's correct though, because I looked at the other service that I see being dbus activated in the journal.  I see rtkit-daemon being successfully activated, and it's disabled (but it is active and running).  Now, in this case, it's not an alias that it's picking up, it's a BusName=org.freedesktop.RealtimeKit1 in its unit file (Service section) that it's looking for and finding.  Hmm, so I guess with Aliases it works like avahi is working (or not, in this case), and with BusNames it works like rtkit-daemon.  Ok.  The other ones being dbus activated are static (polkit, colord, udisks2), which makes more sense.  They're not configurable as far as enabling or disabling, they're just activated on demand when they're needed.

So: 1. Is this a real bug? 2. Does it still happen with MGA5?

Keywords: (none) => NEEDINFO

This was reported for Mageia 5.  As for whether it's a real bug or not, I don't know.  Maybe this should be a BusName instead of Alias, maybe the whole Alias scheme is broken and/or doesn't make sense.  Could use some feedback from Colin on my last comment (Comment 8).

Sorry for late reply... lost in my "inbox of perpetual ignorance"... :s

(In reply to David Walser from comment #8)
> (In reply to Colin Guthrie from comment #7)
> > You said: "In this case, the file it's looking for is
> > /usr/share/dbus-1/system-services/org.freedesktop.Avahi.service" in
> > reference to the error message. I think this is incorrect as I think the log
> > message is referring to the field SystemdService= in the file you referred
> > to (/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service)
> 
> So, I think what you're telling me is that I was mistaken in thinking that
> it's looking for that file (which isn't a surprise, since I thought service
> files should be in /lib/systemd/system and not
> /usr/share/dbus-1/system-services)

Keep in mind that this is a terminology clash. dbus uses the term "service" (and the filename suffix .service) that, while similar, is separate to systemd's services and .service files.

As dbus and systemd both have supporting code for each other, this confusion is all too easily triggered :s


> when it's actually looking for
> /lib/systemd/system/avahi-daemon.service, which contains
> Alias=dbus-org.freedesktop.Avahi.service in its Install section.

Basically, when dbus activation occurs, dbus looks at *it's* .service file for the bus name. In this case it looks at:

/usr/share/dbus-1/system-services/org.freedesktop.Avahi.service

dbus parses this file and reads the lines:

Exec=/bin/false
SystemdService=dbus-org.freedesktop.Avahi.service

In this case, the "SystemdService=" directive overrides the Exec= directive. When the SystemdService= directive exists, dbus will use systemd to do the service activation. If this directive is not present, then dbus will use the Exec= line to start the service without systemd's help.


So the *systemd* service it's looking for is called:
dbus-org.freedesktop.Avahi.service

This is confusingly similar to the dbus service file name (note the dbus- prefix).

It will look for this in the standard *systemd* service paths: /usr/lib/systemd/system/ and /etc/systemd/system (+ others but not relevant here).

If the avahi-daemon.service is enabled, then this file will exist via means of a symlink (this symlink is created when calling "systemctl enable avahi-daemon.service" thanks to the Alias= directive in the [Install] section of the systemd unit (/usr/lib/systemd/system/avahi-daemon.service)

If you call systemctl disable avahi-daemon.service, this symlink will be removed.

So, in senseless, as I tried and likely failed to explain above, if the avahi-daemon.service is enabled, it will be both started at boot (as part of multi-user.target) but it will also be bus-activated when needed. If you disable it, neither will it be started at boot or bus activated.

Both are tied together.

Hope this is a fuller explanation.

> > I agree the log messages are horrible. It's kinda tricky tho', as the way
> > it's working here is it's relying on an alias to trigger it. If the *dbus*
> > .service file referred to the systemd unit as "avahi-daemon.service" (rather
> > than the alias name dbus-org.freedesktop.Avahi.service) then it would
> > activate it regardless as to whether or not the administrator enabled avahi
> > or not. This might be confusing for an admin to find a service running that
> > was not enabled. This is why this alias scheme is used. Until the unit is
> > enabled, the alias does not exist (it's in it's [Install] section) and thus
> > as far as activation goes, the unit does not exist at all. This results in
> > the confusing error message. Because of this layer of indirection (via the
> > alias) I can see that fixing the error message to be more user friendly
> > might be a bit tricky :(
> 
> So, when it goes looking for dbus-org.freedesktop.Avahi.service, it doesn't
> know that the reason it can't find it is that it's an alias to a disabled
> service, so it can't easily print a more helpful error message.  I guess
> that makes sense.

Yeah, exactly.

> What doesn't make as much sense (as you already mentioned earlier) is having
> a scheme where it wants to dbus activate a service that's already enabled,
> in which case it should already be running anyway, and that's the only case
> in which it works.  I'm not sure I see the point of dbus activating it at
> all then :o)

Valid points. In this case it comes down to user expectation.

If a user enables the service, they kinda expect it to be running when they look for it. So that's why it starts at boot.

Now, we *could* make it such that bus activation works, even if the service is disabled (we would do this by either removing the Alias= line and shipping the symlink it creates in /usr/lib/systemd/system as part of the package, or by changing the dbus .service file to refer to the native systemd service unit). This would start avahi even if the sysadmin had disabled it. The sysadmin would have to mask the service to prevent bus activation. I think this has drawbacks too as admins would wonder the opposite - why is it running when it's disabled!

So both options suck!

A better option would be to have a unit state "awaiting activation" such that it knows when the unit type is dbus (and there is a valid BusName=) and it's not masked, then it could, at any point, be activated. This obviously requires changes in systemd.

As this stuff is undergoing a *lot* of change when moving towards a dbus-daemon free world, I expect we'll see polish in this area in the coming year or so.

Also, avahi-daemon will also die fairly soon too and be subsumed into networkd. So this problem will disappear then too ;)


> I'm not sure that's correct though, because I looked at the other service
> that I see being dbus activated in the journal.  I see rtkit-daemon being
> successfully activated, and it's disabled (but it is active and running).

Indeed.

> Now, in this case, it's not an alias that it's picking up, it's a
> BusName=org.freedesktop.RealtimeKit1 in its unit file (Service section) that
> it's looking for and finding. 

Nope, not quite correct.

It's *dbus* service file (/usr/share/dbus-1/system-services/org.freedesktop.RealtimeKit1.service) has this line:

SystemdService=rtkit-daemon.service

This is the native unit name (it's not via a dbus-org.freedesktop.RealtimeKit1.service Alias= directive in the /usr/lib/systemd/system/rtkit-daemon.service systemd service.

So in *this* case, it will be bus activated even if the user has disabled it. 

This is indeed inconsisent.

> Hmm, so I guess with Aliases it works like
> avahi is working (or not, in this case), and with BusNames it works like
> rtkit-daemon. 

No, not quite, it's actually less cryptic than that if you look at the dbus activation flow (from dbus .service -> systemd .service) but I hope I explained it above.

> Ok.  The other ones being dbus activated are static (polkit,
> colord, udisks2), which makes more sense.  They're not configurable as far
> as enabling or disabling, they're just activated on demand when they're
> needed.

To be honest, I suspect rtkit should be the same as that (i.e we should just ditch the [Install] section), but I'd say that's a rtkit problem rather than an avahi one per-se.

I agree it's not super consistent tho'. I guess there is a line somewhere between "core, needed system services" (a la polkit, udisks, colord and (maybe) rtkit) and "really nice to have services" (a la avahi). This is very much a blurred line!

Hope that helps.