Doesn't work properly under Wayland #159

hedayat · 2016-10-29T18:03:42Z

I've tried this extension under Wayland (Fedora 25), but it doesn't work on login. It reports a timeout error connecting to hamster DBus service (don't have the exact error message right now, can report later).

Surprisingly, sometimes it suddenly starts to work (probably after locking/unlocking the screen or some other events, but have not found the exact procedure to make it appear). But it doesn't work right after login anyway.

Update: error message:
Gio.IOErrorEnum: Error calling StartServiceByName for org.gnome.Hamster: Timeout was reached

And current running services:
% pgrep -af hamster
10067 python2 /usr/bin/hamster-service

hamster-windows-service seems to be unable to run automatically when using Wayland, but works fine under X.

elbenfreund · 2016-10-29T18:09:35Z

Hello. May #89 or #115 be related?
Can you please check if the hamster dbus service is actually running?

hedayat · 2016-10-29T18:15:00Z

Not related to #89, but could be duplicate of #115. However, I switched to Gnome on Xorg and it worked fine. Switched back to Gnome on Wayland and didn't work. I'm not using that system right now, but IIRC after login one of the services was running but the other one was not.

Note: it has never failed when using Xorg, so there is at least something related to either Wayland itself or how things are started under it.

hedayat · 2016-10-29T18:55:54Z

Seems to be really duplicate of #115, except that I've not been able to get it running right after login even with logging in using Xorg before that.

hedayat · 2016-10-31T06:55:28Z

Seems to be really duplicate of #115, except that I've not been able to get it running right after login even with logging in using Xorg before that.

I think I know why this happens: AFAIK, in Fedora 25, when you log out, all your user processes are terminated including hamster services.

hedayat · 2016-10-31T08:26:20Z

More info: the login process is not important. If I disable this plugin, log in to the system, and then try enabling Hamster extension, it takes long and doesn't start with the same error. Apparently, there is a difference between how /usr/bin/hamster-service is activated and how /usr/bin/hamster-windows-service is activated; and the latter doesn't work under Wayland.

a-m-s · 2016-10-31T17:45:35Z

I think it's already been said that this is a Fedora specific problem, but just to be clear ....

The extension works fine in Wayland under Arch Linux. However, there are no fancy services (??) and I start the main hamster app via Startup Applications, in Gnome Tweak.

hedayat · 2016-10-31T21:23:52Z

... and I start the main hamster app via Startup Applications, in Gnome Tweak

Maybe this is why you don't see the problem (because running main hamster app will start both services). If you are using Gnome 3.22 under Wayland, I'd expect to be able to see the same problem. I highly doubt that this is a Fedora only problem.

elbenfreund · 2016-11-02T09:29:07Z

I am sorry if i do not contribute to this discussion. I personally lack experience with wayland and as this seems related to legacy hamsters services I can not help much with this. I do however wonder if this isn't a packaging issue, as the way services are handled is ultimately up to distributions maintainer isn't it?

hedayat · 2016-11-02T13:35:40Z

If you see anything which might show it can be a packaging bug, please let me know. But the package itself is working properly. The services are also started automatically when the application is started. The only problem is when the extension is started first. (There is even no problems if I start the services using the dbus-send commands which are given in comments in extension.js).

pwithnall · 2017-01-23T10:37:50Z

I have some changes which partially address this, though they do not fix the problem entirely. They at least make the plugin not explode for the duration of your shell session after failing to get a proxy for the Hamster services on D-Bus. I haven’t had time to clean them up properly for submission (and won’t have time to do so, especially if contributing to Hamster requires signing a CLA), but they might inspire a proper fix from someone else:

https://github.com/pwithnall/hamster-shell-extension/tree/gnome-3-22-fixes

waldyd · 2017-04-14T19:15:05Z

The following is being prompted on fedora 25 (Wayland):

gnome-shell[1991]: JS LOG: Extension "[email protected]" had error: Gio.IOErrorEnum: Error calling StartServiceByName for org.gnome.Hamster: Timeout was reached
dbus-daemon[1896]: [session uid=1000 pid=1896] Activating service name='org.gnome.GConf' requested by ':1.56' (uid=1000 pid=2158 comm="python2 /usr/bin/hamster-service " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
org.gnome.Shell.desktop[1991]: Window manager warning: Trying to remove non-existent keybinding "show-hamster-dropdown".
gnome-software-service.desktop[2518]: 17:33:54:0639 Gs  no app for changed [email protected]
gnome-shell[1991]: JS LOG: Extension "[email protected]" had error: TypeError: this.extension is null
gnome-shell[1991]: JS LOG: Extension "[email protected]" had error: Gio.IOErrorEnum: Error calling StartServiceByName for org.gnome.Hamster.WindowServer: Timeout was reached
gnome-software-service.desktop[2518]: 17:34:19:0749 Gs  no app for changed [email protected]
gnome-shell[1991]: JS LOG: Extension "[email protected]" had error: TypeError: this.extension is null

Nevertheless, it is sometimes showed on topbar:

jasuarez · 2017-04-18T11:11:53Z

FWIW, I've applied commit jasuarez@61286f0

And ensured hamster-windows-service is automatically run (details on commit message).

ghost · 2017-05-24T19:40:08Z

FWIW, I've applied commit jasuarez/hamster-shell-extension@61286f0

Just to be sure, Does it solved the issue for you @jasuarez ?

jasuarez · 2017-05-25T07:29:37Z

Yes, it works for me. Now I can use Hamster in my Wayland desktop

hedayat · 2017-05-25T12:24:31Z

But normally, the hamster-windows-service should be run automatically when requested by DBus. You should not need to manually add it to be auto-started.

jasuarez · 2017-05-25T15:34:24Z

@hedayat yes, it should. And it does on Xorg, but for some reason not in Wayland (at least on my Fedora 26).

So if it runs for you, just skip the step of launching it.

hedayat · 2017-05-26T15:28:49Z

No! I wanted to say that a proper fix should probably fix that too. I don't know why it doesn't work, but I think it should!

jasuarez · 2017-05-26T15:47:06Z

@hedayat Oh, sorry. I agree. But it should start the daemon before the extension is run, which happens when the shell is started.

tomasruprich · 2017-05-29T08:36:32Z

Thanks @jasuarez, finally this extension works on my Fedora again!

hedayat · 2017-06-20T13:06:23Z

This is a general problem with all extensions which depend on DBus: benzea/gnome-shell-extension-redshift#19

It seems that it is related to how/when DBus is launched in a wayland session.
It might provide some clues: https://lists.debian.org/debian-devel/2016/08/msg00554.html

hedayat · 2017-06-20T13:33:09Z

Additionally, I think this bug is only seen in Fedora because probably others are NOT using the same method as Fedora to launch DBus user session. Fedora uses systemd user sessions to start user's dbus session.

elbenfreund · 2017-10-13T13:57:34Z

So, am I correct to assume that:

This is a Fedora specific issue
It is not really about hamster-shell-extension or even hamster-time-tracker but about how Fedora handles dbus-service startup?

hedayat · 2017-10-14T23:22:10Z

About the first point: it might be Fedora specific right now, but I guess it'll start to happen on others as they start to move to Wayland too.

I'm not sure about the second. While it seems to related to dbus-service startup, there might be something that can be done in hamster-shell-extension (or maybe hamster-time-tracker).

rhertzog · 2018-03-08T21:59:32Z

Debian Unstable switched to wayland a while ago too and I have never had this problem here.

elbenfreund · 2018-03-11T21:48:46Z

So, where are we on this. There seem to be reports about things working under Arch as well as Debian running wayland. Is this still tru @a-m-s ?
Also, Does #200 help tracking down any issues with the service not running?

a-m-s · 2018-03-12T09:45:06Z

AFAICT, the Wayland problem was only ever that the Hamster background process wasn't being started the same way. I'm still using the extension every day, still using it with Arch, and still launching the daemon via Startup Applications.

However, I do get Gnome Shell crashes that sometimes coincide with my using this extension. In Wayland those crashes are catastrophic, so I tend to use Xorg most of the time.

elbenfreund · 2018-03-12T10:15:36Z

Thanks @a-m-s . Do you have time to take the current dev branch for a spin and see if those crashes are still an issue?

a-m-s · 2018-03-12T10:57:50Z

Is it compatible with the old, stable hamster daemon, or would I need to upgrade that to the development version too?

elbenfreund · 2018-03-12T11:13:42Z

It is targeted towards old hamster and does not support the new hamster-gtk yet.
It seems however, that the develop branch breaks i18n.

This fixes gnome-shell freezes under Wayland (at least in Fedora), as it seems that it stalls gnome-shells main loop. fixes projecthamster#159

hedayat · 2018-03-13T06:53:00Z

As it is fixed, I still really doubt that it was Fedora specific. @a-m-s is actually manually starting services, so apparently he also had problems without them. And about @rhertzog, are you sure that you are on Wayland? e.g. on hybrid GPU systems gnome always falls back to Xorg, unlelss you force with with an environment variable.

Anyway, the fix should work for everyone, and I've even seen that others also have done this too in other projects (e.g. webmastak/gnome-shell-extensions-mediaplayer@5417b8e) so this should be the correct way to do that.

rhertzog · 2018-03-13T08:06:56Z

@hedayat Yes, I'm sure that I am on wayland. And I believe that I also use systemd user sessions. It's possible that I'm affected by the deadlock you are referring to but that I only rarely trigger it... but the dbus activation is working fine with systemd and I believe that was the main point of this ticket. For some persons the dbus user session was not yet available at the time of the startup of the extension. And this specific problem I have never seen.

hedayat · 2018-03-13T08:38:56Z

Thanks for your response.
No, the hints about the issue being related to dbus startup was misleading (that was my fault!). Actually, I've pointed out in previous comments (#159 (comment)) that it is not related to startup, but I myself have forgotten about it. The issue is completely irrelevant to dbus service startup: even when I logged in with the extension disabled, and double-checked that dbus user session is already running, and then tried to enable the extension, it didn't start correctly. And what happened was this:

I enabled the extension
A dbus log was generated that it has received a request to enable Hamster dbus service
Nothing happens until dbus service activation times out in hamster extension code, and an error is generated that activation times out
Right after extension time out, dbus says that it has activated Hamster service successfully (Clearly, things have been stalled completely in extension code).

It always happen for me, so if you are not affected, you probably will never see it. So, there is either something special in either of Debian or Fedora, or ... ? (Can't say anything about Arch, because he was manually starting hamster services using autostart feature of the desktop).

Anyway, the fix seems to work for everyone, so it shouldn't matter if the issue was distro specific or not.

This commit establishes *async* set up of the api and window proxy instances. In order to prevent blocking calls the actual ``enable``ing now happens in a new ``deferred_enable`` method that is called as a collback. Some extra provisions have been added to make sure that ``deferred_enable`` is executed only once even if 'called' multiple times. Ref.: projecthamster#159

elbenfreund · 2018-03-13T11:24:26Z

I merged hedayat's patch and await your feedback :)

a-m-s · 2018-03-13T11:57:50Z

@elbenfreund I tried the develpment version and Wayland. It appears to work the same in Wayland as in X: everything looks fine, but the list doesn't update right away when I add a new activity (although the activity shows in the overview fine), and the extension (apparently) crashed my session randomly. I'll be switching back to the stable version and X.

I added the app to Startup Applications because I want the window to open when I log in. I've been doing that since before I had the extension. It's possible that I accidentally hid the problem for myself?

elbenfreund · 2018-03-13T12:55:30Z

and the extension (apparently) crashed my session randomly

@a-m-s So, things have not improved (under Wayland) for you, right?

It's possible that I accidentally hid the problem for myself?

To be honest, at this stage it is too long that I last dwelt into legacy hamers's codebase to remember how exactly it handles service launches of the top of my head. As far as my understand goes, this issue is (no longer) related to problems with the dbus service not running. With the #200 merged, this should no longer fail silently but at the very least give you a notification.
Which leaves this issue as one about (random?) crashes.. As I personally do not experience those, I am only of limited help tracking those down. :(

Note:
I will revisit my general changes during the refactoring, I have the slight suspicion I may have altered some of the async service calls to be syncronous. If so, this may explain the problems...

a-m-s · 2018-03-13T15:40:59Z

I found the extension fully functional (meaning everything I tried worked), but I had the gnome session crash as I was adding a new activity via the extension. It could be a coincidence, but that seems unlikely. It was not the first time I had added an activity that session.

I've also experienced shell crashes in X, but those are typically not fatal.

Anyway, I believe that's probably bug #212, not any kind of Wayland related communication issue.

elbenfreund · 2018-03-16T12:40:27Z

I would like to streamline our remaing "crash related" issue a bit. As far as I can tell, #159 and #198 have been addressed to the extend that was/is specific to wayland/fedora. The extension should be handling missing services better and a bunch of unrelated issues brought up in those issues has been cleared to.

In order to deal with the remaining crashes, I suggest moving the conversation to #212, with regards to the delay in visual updates on the panel: #205

Does this work for you? Are there any open questinons that are specific to this particular issue title?

hedayat · 2018-03-16T20:45:15Z

Yes, I agree. No, I think it this one is resolved. Thanks.

elbenfreund · 2018-03-16T21:23:24Z

👍

elbenfreund added the bug Code working other than specified. label Nov 2, 2016

LucileQ mentioned this issue Dec 1, 2016

Doesn't work on fedora23 #108

Closed

breakpoint8088 mentioned this issue Jul 12, 2017

Not working on fedora 25 #169

Closed

elbenfreund marked this as a duplicate of #169 Jul 18, 2017

elbenfreund added this to the 0.10.0 milestone Oct 13, 2017

elbenfreund added the waiting for feedback Feedback is required before further work on this can be done. label Oct 13, 2017

elbenfreund mentioned this issue Oct 13, 2017

Not working on Fedora 26 (GNOME 3.24.2) #198

Closed

hedayat added a commit to hedayat/hamster-shell-extension that referenced this issue Mar 12, 2018

Use asynchronous DBus proxy creation

9644327

This fixes gnome-shell freezes under Wayland (at least in Fedora), as it seems that it stalls gnome-shells main loop. fixes projecthamster#159

hedayat mentioned this issue Mar 12, 2018

[#159] Use asynchronous DBus proxy creation #239

Merged

elbenfreund closed this as completed in #239 Mar 13, 2018

elbenfreund reopened this Mar 13, 2018

elbenfreund closed this as completed Mar 16, 2018

elbenfreund removed the waiting for feedback Feedback is required before further work on this can be done. label Mar 26, 2018

Doesn't work properly under Wayland #159

Doesn't work properly under Wayland #159

Comments

hedayat commented Oct 29, 2016 • edited Loading

elbenfreund commented Oct 29, 2016

hedayat commented Oct 29, 2016

hedayat commented Oct 29, 2016

hedayat commented Oct 31, 2016 • edited Loading

hedayat commented Oct 31, 2016

a-m-s commented Oct 31, 2016

hedayat commented Oct 31, 2016

elbenfreund commented Nov 2, 2016

hedayat commented Nov 2, 2016

pwithnall commented Jan 23, 2017

waldyd commented Apr 14, 2017 • edited Loading

jasuarez commented Apr 18, 2017

ghost commented May 24, 2017 • edited by ghost Loading

jasuarez commented May 25, 2017

hedayat commented May 25, 2017

jasuarez commented May 25, 2017

hedayat commented May 26, 2017

jasuarez commented May 26, 2017

tomasruprich commented May 29, 2017

hedayat commented Jun 20, 2017

hedayat commented Jun 20, 2017

elbenfreund commented Oct 13, 2017

hedayat commented Oct 14, 2017

rhertzog commented Mar 8, 2018

elbenfreund commented Mar 11, 2018

a-m-s commented Mar 12, 2018

elbenfreund commented Mar 12, 2018

a-m-s commented Mar 12, 2018

elbenfreund commented Mar 12, 2018 • edited Loading

hedayat commented Mar 13, 2018

rhertzog commented Mar 13, 2018

hedayat commented Mar 13, 2018

elbenfreund commented Mar 13, 2018

a-m-s commented Mar 13, 2018

elbenfreund commented Mar 13, 2018

a-m-s commented Mar 13, 2018

elbenfreund commented Mar 16, 2018

hedayat commented Mar 16, 2018

elbenfreund commented Mar 16, 2018

hedayat commented Oct 29, 2016 •

edited

Loading

hedayat commented Oct 31, 2016 •

edited

Loading

waldyd commented Apr 14, 2017 •

edited

Loading

ghost commented May 24, 2017 •

edited by ghost

Loading

elbenfreund commented Mar 12, 2018 •

edited

Loading