Gnome-shell-extension-gsconnect: gsconnect filled my disk with logging

[rrthomas]

Describe the bug

My computer ran out of disk space. The problem turned out to be /var/log/syslog, which was 338GB, full of copies of:

Oct  2 15:42:21 dwks org.gnome.Shell.Extensions.GSConnect[1429947]: == Stack trace for context 0x556b68f6e1a0 ==
Oct  2 15:42:21 dwks org.gnome.Shell.Extensions.GSConnect[1429947]: #0   556b6901e800 i   /home/rrt/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js:729 (3e134658d178 @ 963)

Steps To Reproduce:

I don't know how to reproduce this. I stopped the extension, killed the daemon process, and it did not happen again so far.

GSConnect: 43 (user)
GJS:       16403
Session:   x11
OS:        Ubuntu 20.04.1 LTS
--------------------------------------------------------------------------------

(Sorry, no relevant messages.)

System Details (please complete the following information):

• GSConnect version: 43
  
  
  
  • Installed from: GNOME Extensions Website
  
  
• GNOME/Shell version: 3.36
• Distro/Release: Ubuntu 20.04

GSConnect environment (if applicable):

• Paired Device(s): Sony XZ1 compact
• KDE Connect app version: 1.14.2

Additional Notes:

The time stamp of the endless log messages is precisely when my phone connected to my home network for the first time today.

[andyholmes]

Thanks for reporting, but there's not enough information here for me to track this down. I'll have to wait for more information before I can fix this.

[rrthomas]

What other information could I give if it happens again? I was rather alarmed by my barely-operable computer, so I may have panicked a little!

[andyholmes]

There should be a stack trace somewhere that leads farther back than the main loop (line #729). All that really indicates is that it was an event of some sort, but not where it came from or what it was :/

[rrthomas]

Ah, OK! I had another look, as I have kept just the start of the log where it went wrong, and I cannot find a longer traceback; just in some of the stanzas of the log there is one more line

Oct  2 15:42:21 dwks gjs[1429947]: The offending callback was SourceFunc().

[andyholmes]

Unfortunately that only confirms that it was an event being processed by the loop :/ It might have to wait until the problem reoccurs with a more descriptive backtrace.

[rrthomas]

Thanks again. I don't know whether the absence of backtrace in itself tells you anything?

[andyholmes]

Nope :)

[ferdnyc]

I realize it's not the central issue here and fixing the GSConnect issue that leads to this this is the priority, but I can't understand why Ubuntu still maintains a /var/log/syslog file. They've switched to systemd/journald, no?

One of the advantages to the journal is that its size is capped -- this CAN'T happen with a journal. Not unless you _also_ copy its contents to a flat file, as Ubuntu seem to be doing. (Journald also deduplicates the log output into message catalog references, so it uses its allotted gigs of space much more efficiently than a syslog file. But that's secondary, really.)

[rrthomas]

Thanks for the suggestion, @ferdnyc: I tried removing rsyslog and found that indeed it can be removed from my Ubuntu 20.04 system (it's not "essential"), but it is still "important" (i.e. part of a standard minimal install), so I'm not keen to remove it for now.

[gnusuari0]

I got this too today. I thought it was already fixed but something made GSConnect fill syslog again. daemon.js:729.

[rightaditya]

I also don't have a deeper stack trace to provide (not sure where to look), and I also see that you're not maintaining this project (thanks so much for bringing it this far!) so this is really just for any future maintainer(s), but my log gave this additional line:

Dec 16 00:00:14 cocoa gjs[4904]: Attempting to run a JS callback during garbage collection. This is most likely caused by destroying a Clutter actor or GTK widget with ::destroy signal connected, or using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked.

After that it's the line @rrthomas reported above about SourceFunc() and then the stack trace lines as in his OP.

[darkdragon-001]

Duplicate of #588 ?

[rrthomas]

@darkdragon-001 looks like it, sorry for the dup!