daemon.js spewing null-value errors to journal (by the thousands) about gnome-shell-extension-gsconnect HOT 12 CLOSED

Oh,I should mention that I'm still running... for the most part your last zip from #8, I think. Though I now notice that my local copy is using the folks-cache.py changes I made (detailed in my last comment there), which differ from the commit you made to close the issue. I should try syncing those up. But, any local differences are confined to folks-cache.py, and all other files match the checked-in code. (Of course, folks-cache.py could be involved here.)

Ooh, in FAAACT, I just discovered that $HOME/.cache/gsconnect/contacts/ contains — among a surprising 2294 total files — several with creation dates that exactly match each of the daemon's journal-spew instance. So folks-cache.py is definitely involved.

...Hmm, the dir contains exactly 23 such files, in fact. The same 23 files. Written out during each folks-cache.py run, with new random UUIDs.

It now appears that each time folks-cache.py is being run, on my system, it

1. retrieves the same 23 avatar images,
2. stores them in the cache directory with new random UUID names,
3. completely regenerates contacts.json with those new avatar file paths,
4. leaves all the previous files in place,
5. and somehow triggers daemon.js to log thousands of null-value errors to the journal.

So, given the inconsistency between my local copy of the python code and the checked-in code, I'm going to say that this issue boils down to "something's up with folks-cache.py", and start by replacing my local copy with the repo HEAD so it's in a known state. These problems could very well be my own fault, so let's put this report on hold for the moment. I'd hate for you to go chasing a bug that's not even in your code.

from gnome-shell-extension-gsconnect.

Hmm, I don't know if this should be closed just yet. I managed to trigger a new burst of these messages in the latest, greatest, #8-fixing code.

It turns out that they're caused by executing a manual python3 folks-cache.py while the GSConnect daemon is running. Now, maybe that's just a no-no and the simple solution is to say, "Don't do that." But since the daemon itself spawns folks-cache.py runs under certain cases, presumably it would still be causing the same problems for itself?

from gnome-shell-extension-gsconnect.

(And when I say "a burst", I mean 400 messages in the space of a few seconds.)

from gnome-shell-extension-gsconnect.

It's hard to say, most of that affected code had been replaced with entirely different code now. Previously I had a GtkEntryCompletion model set to repopulate whenever the contacts.json file was changed on disk, but use a much more simplified approach on the widget side. I'm also planning to revisit the way the contacts are cached, but I'm not sure exactly what I'll be doing yet.

If you like you can use this ZIP which is up to date as of this morning:

[email protected]

from gnome-shell-extension-gsconnect.

I'm going to assume this is fixed or invalidated since I don't use a Gtk.EntryCompletion or Gtk.ListStore for storing contacts anymore.

from gnome-shell-extension-gsconnect.

Oops, sorry. I'd gotten busy with other things, and didn't have a chance to test the new zip until just now.

Looks like it has cleared up, yes — thanks! I almost reported that it hadn't, since I was still getting those messages by the hundred after running python3 folks-cache.py, but then I noticed that the daemon.js process on my machine was two days old. Seems even turning off the extension, completely replacing the directory, and restarting gnome-shell (I'm still running Xorg; Nvidia proprietary drivers) wasn't enough to kill it off. It's certainly resilient, I'll give it that! Once I manually killed the process, it respawned with the new code.

So far everything here looks good, along with another issue I'd been dragging my feet on reporting (since I knew the code was in flux and I wasn't current) where SMS replies weren't being directed to already-open conversation windows. But that's no longer the case, which is awesome.

from gnome-shell-extension-gsconnect.

Looks like it has cleared up, yes — thanks!

Glad to hear it, I hope to release v7 in the next day or so with a WebExtension for Chrome and Firefox, along with all the other fixes.

Seems even turning off the extension, completely replacing the directory, and restarting gnome-shell (I'm still running Xorg; Nvidia proprietary drivers) wasn't enough to kill it off.

That might be a bug I'll have to look into :/ The daemon is set to watch its own file and quit if it's changed, replaced or deleted to allow for upgrades and removal.

With regard to Xorg, I can tell you that's not a bad idea. Even running Gnome 3.26 I can tell you Wayland is not ready for prime-time, unless you like your popup menus squished and on the other side of the screen ;)

from gnome-shell-extension-gsconnect.

That might be a bug I'll have to look into :/ The daemon is set to watch its own file and quit if it's changed, replaced or deleted to allow for upgrades and removal.

That might be my fault. As I said I "completely replaced the directory" — by which I mean, I moved it out of the way and created a new one to unzip the current code into, so I'd be able to diff them for comparison purposes. So the old daemon's source file was still there, unchanged. Sounds like I did the one thing it wouldn't notice, oops. I'll keep that in mind for the future.

from gnome-shell-extension-gsconnect.

Sounds like I did the one thing it wouldn't notice, oops.

That's okay, and helpful description, I'll just set it to watch for moves as well. When you're programming for linux accounting for power-users just comes with the territory ;)

from gnome-shell-extension-gsconnect.

...Though, before doing any of that, I did switch the extension to Off in gnome-tweak-tools. Seems like that should also kill the daemon, right?

from gnome-shell-extension-gsconnect.

Unfortunately not, what it does do is remove the .desktop file and DBus .service file preventing it from being automatically started.

Anytime the screen locks or the desktop "state" changes in any way Gnome Shell calls disable() on all the extensions, that's actually why there's a separate daemon. Otherwise all the code could be in the extension instead of a separate process. This means the daemon has to ignore extension disabling, otherwise it would quit whenever the screen blanked, locked or went idle.

Compare this with the Email Notifications extension which gives you a flurry of notifications when the screen unlocks, and Dropdown Terminal which uses a daemon to keep processes running when the screen is off.

from gnome-shell-extension-gsconnect.

Anytime the screen locks or the desktop "state" changes in any way Gnome Shell calls disable() on all the extensions, that's actually why there's a separate daemon.

Hm, Github has neither "Wow" nor "Aha!" among its comment reactions, so I'll just register a combination of those two the old-fashioned way, with actual words.

from gnome-shell-extension-gsconnect.