Bug 1490959

I noticed one difference between the two systems, the non-working machine has two .service files with org.freedesktop.Notifications names
at /usr/share/dbus-1/services/, one is the above for MATE, the other one is org.kde.plasma.Notifications.service. I just verified that if I move away the one for Plasma, then it starts working as expected, the MATE service is auto-started on demand and so on, like before.

Thus maybe the issue is with D-Bus, I do not know, to tell it somehow which .service to prefer when running MATE and when Plasma. Or run MATE's service after login and disable auto-stop of it.

And I forgot to add: that plasma .service file doesn't exist in the version in
Fedora 25, which explains why it wasn't the problem before the update to
Fedora 26.

Since services like this can potentially have multiple providers, if a DE expects a particular implementation, it really ought to explicitly launch that one (and not rely on simple dbus activation (particularly problematic since dbus has no mechanism to prefer or prioritize providers)

Right, I was afraid of it. In that case the fix comes to MATE itself to:
a) do not auto-stop mate-notifcation-daemon
b) start it on MATE start (login) and stop it on MATE end (logout/restart);
   it should not be tricky for multiple users being logged at the same time
   (the "switch user" feature), as long as the MATE session stops only
   the process which it started, not all running (not using pkill/killall).
   There can be easier ways to achieve that, of course, I'm only giving my
   opinion.

*** Bug 1498276 has been marked as a duplicate of this bug. ***

(In reply to Milan Crha from comment #4)
> Right, I was afraid of it. In that case the fix comes to MATE itself to:
> a) do not auto-stop mate-notifcation-daemon

We do not auto-stop the daemon because the daemon is called via dbus from applications.
In other words, we do not start the or stop the notification daemon.

> b) start it on MATE start (login) and stop it on MATE end (logout/restart);
>    it should not be tricky for multiple users being logged at the same time
>    (the "switch user" feature), as long as the MATE session stops only
>    the process which it started, not all running (not using pkill/killall).
>    There can be easier ways to achieve that, of course, I'm only giving my
>    opinion.

There is an PR about using auto-start for the notification-daemon.
https://github.com/mate-desktop/mate-notification-daemon/pull/53
Read discussion.
Problem is that all notification-daemons needs to do the same ;-)
If one use dbus-activation, for example the daemons from kde or xfce, those daemon will be prefered by applications.
Sadly xfce devs had said clear that they won't change be haviour of their daemon.
For reference:
https://bugzilla.xfce.org/show_bug.cgi?id=7950 - wontfix
https://bugs.debian.org/640082 - wontfix
For this reason MATE upstream decided not to merge the PR in 2015.

Well, if you like to discuss this please use upstream PR/report.
I can change nothing for myself.
Maybe  you have the time and the nerves to coordinate a change for all notification-daemons, as you have a Redhat address.
Sorry, i am not paid by a linux company, so i don't have the time for this job
And my free time is more and more limited ;-)

(In reply to Wolfgang Ulbrich from comment #6)
> We do not auto-stop the daemon because the daemon is called via dbus from
> applications.

This statement is not correct. See the second part of the proposed change, "remove exit-on-idle":
https://github.com/mate-desktop/mate-notification-daemon/pull/53/commits/9dd47e22f8e40afaa076662ec257810ba50ed0e7

> There is an PR about using auto-start for the notification-daemon.
> https://github.com/mate-desktop/mate-notification-daemon/pull/53
> Read discussion.
> Problem is that all notification-daemons needs to do the same ;-)

Not necessarily. As long as you start your daemon first, it'll be used by D-Bus and everything will work. My personal opinion on the pull request is that it's the correct way to do, also to fix this issue, no matter what other desktop environments will do. Furthermore, the change contains "OnlyShowIn=MATE;" which makes things correct. I'm unsure about "NoDisplay=true", but it doesn't matter at the moment.

> If one use dbus-activation, for example the daemons from kde or xfce, those
> daemon will be prefered by applications.

No. Applications cannot pick which will be used. Applications use D-Bus interface and D-Bus picks which service is started (if none is started already). See comment #3 above. Furthermore, most of the applications use libnotify, which hides this detail nicely.

> I can change nothing for myself.

Right. I do not know whether including the pull request in Fedora only, as a proof of concept and proper behaviour, would be too much trouble for you. Bringing custom patches in packages is always a pain. The only semi-valid argument in the pull request is that "if the daemon crashes, things break". Having an excuse of "this doesn't work in common scenario, because what we can change may not work in corner case scenario" feels similar to XFCE statements. I'm sorry.

I never saw the daemon crash here, running MATE, though it can be that it never run for too long. Nonetheless, you can do it similarly as gnome-shell-calendar-server does it with evolution-calendar-factory. When it disappears, the gnome-shell-calendar-server restarts it. I didn't search how they do it, but I can imagine that a cooperation between this daemon and the core of MATE in a way of listening on the D-Bus interface owner and when it disappears, then start the process (not the service) again, would make the trick. You may make it smart enough to not keep it restarting too often, like if there's really some big trouble with the binary that it prevents it to be running, to not keep restarting it in a loop ad infinity, but that's a trivial thing to do.

Eventually, if the core MATE has some plugin/module functionality, then the "keep mate-notification-daemon running" code can be part of the daemon code, without breaking abstraction.

I do not have github account, thus I cannot comment on the upstream tracker, but I believe I can help to provide such code for some core part of the MATE, if you tell me which one would be the best. Then you might eventually upstream that change to the pull request.

> Maybe  you have the time and the nerves to coordinate a change for all
> notification-daemons, as you have a Redhat address.

Nah. Please, do not take it this way. I just try to help, it has nothing to do with Red Hat. I understand the pain about coordination between projects, the more when they are concurrent to each other. Not talking that people are stubborn. When reading the discussion on the MATE side, it seems to me that they are no better than XFCE (see the #10, the first response was: "We dont think we need this in MATE."). :) Maybe they (MATE folks) will/did change their mind.

Looks like you know all better how mate-notification-daemon works......:-)
Again, the PR isn't merged and m-n-d isn't started by mate-session-start and nobody stops the daemon.
All is done via dbus by an application.
And if more than one notification-daemon is installed than you have a problem.

(In reply to Wolfgang Ulbrich from comment #8)
> Looks like you know all better how mate-notification-daemon works......:-)

I hope not, it was just after brief code reading, thus likely I'm wrong in many aspects.

> nobody stops the daemon.

All correct except the above. Again, the mate-notification-daemon is currently set to stop itself after some time of inactivity. Thus it's not "nobody stops", but "the daemon stops itself". Thus when even you add it do the "start after login" list of applications, it'll not help for long.

Feel free to close this in favour of the upstream request. This surely cannot be fixed on the distribution level. Except if you'd like to use Fedora as a proof of concept, as suggested above.

(In reply to Milan Crha from comment #9)
> (In reply to Wolfgang Ulbrich from comment #8)
> All correct except the above. Again, the mate-notification-daemon is
> currently set to stop itself after some time of inactivity. Thus it's not
> "nobody stops", but "the daemon stops itself". Thus when even you add it do
> the "start after login" list of applications, it'll not help for long.
> 
Ok, i think there was a bit miss understanding here.
You're right, with idle-activation the daemon keeps running for a while after an application had call him via dbus.
But, mate-session-manager doesn't start the daemon with session-start.
Currently, it is started first by dnfdragora-updater, which is runing after session-start.

> Feel free to close this in favour of the upstream request. This surely
> cannot be fixed on the distribution level. Except if you'd like to use
> Fedora as a proof of concept, as suggested above.

I am using fedora for myself, so it isn't a proof of concept for me ;-)



(In reply to Milan Crha from comment #7)
> I do not have github account, thus I cannot comment on the upstream tracker,
> but I believe I can help to provide such code for some core part of the
> MATE, if you tell me which one would be the best. Then you might eventually
> upstream that change to the pull request.
A github account you can get for free.
As i am not paid by Redhat or get some donation from fedora for all my work here, i have to earn my money with other stuff and my time is more and more limited.
Sorry, i don't have the time to forward messages from rhbz to github.

(In reply to Wolfgang Ulbrich from comment #10)
> I am using fedora for myself, so it isn't a proof of concept for me ;-)

Do you have installed multiple desktop environments where at least one other (than MATE) provides its own D-Bus service file serving the freedesktop notification interface? If not, then you do not have proper environment. If yes, then you might be just lucky (see the end of comment #3).

Pity the upstream was not willing to fix this back in 2015. Maybe more people will get into the trouble which will finally convince them. The change is not huge and it will keep them users. Which eventually means that your free time work you dedicate to Fedora and the MATE project will not be wasted.

Feel free to close this bug report in whatever resolution fits you the best. I didn't file it to steal any of your free time, which you can surely spend better than on this bug report.

I appreciate your work on Fedora, as a regular user of it.

Also running into this bug.
I did not quite understand from the above if there is a work-around or not.

Is simply deleting
org.kde.plasma.Notifications.service
an option?
Or will that break running plasma occasionally?


Note, nm-applet doesn't like it when there is no notification-daemon (icons are not updated).
nm-applet --no-agent will help.

(In reply to Mark van Rossum from comment #12)
> Also running into this bug.
> I did not quite understand from the above if there is a work-around or not.
> 
> Is simply deleting
> org.kde.plasma.Notifications.service
> an option?
> Or will that break running plasma occasionally?
> 
> 
> Note, nm-applet doesn't like it when there is no notification-daemon (icons
> are not updated).
> nm-applet --no-agent will help.

I don't know much about kde as i never use it.
Rex, please can you help?

Looks like this is another case of: if a DE expects a particular implementation, it should autostart the service explicitly and not rely on dbus activation.

Just for info:
I deleted my plasma desktop from my system (gnome,Mate, and xfce are left),
and now things work as expected.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.