Closed JPvRiel closed 4 years ago
Hi @JPvRiel, sorry I can't help you with this particular issue since I am not sure what's wrong here. I maintain this fork so that it is made compatible with new GNOME Shell releases and user submitted patches are actively merged into the project. I do not actively develop it.
If you (or anyone else) gets a working fix for the issue, please generate a PR. I will be happy to merge it.
Thanks, unfortunately my guess is it's several bugs piling on top of each other... specific touchpad driver bug + journald/syslog dup message filter bug/limitation along with gnome-shell extension logging underneath this. A fix/PR to touchpad indicator would at least not flood syslog.
I guess line 740 in the extension is a place to start, but Gjs null ERROR in gnome-shell could be be part of an underlying trigger:
Feb 11 11:03:07 HOSTNAME gnome-session[4205]: (gnome-shell:4349): Gjs-WARNING **: JS ERROR: (null)
Feb 11 11:03:07 HOSTNAME gnome-session[4205]: touchpadIndicatorButton<._fingertouch_changed@/home/user/.local/share/gnome-shell/extensions/touchpad-indicator@orangeshirt/extension.js:740
I have the same / similar problem using a Bluetooth mouse on an HP Pavilion running Fedora23. One possibly important point is that I seem to get the problem when coming out of suspend mode. If there is any further information I can provide to help diagnose a fix, please let me know:
Gnome Shell Version: 3.18.5 Touchpad Indicator Version: 25 Touchpad(s): SynPS/2 Synaptics TouchPad Synclient: Not found or used on your system. Xinput: Is installed. Switch Method: Gconf
My gnome 3.18 Ubuntu 16.04 LTS environment died again today with /var/log filled up by this flooding bug. I haven't had time to dig into the extension's source and find the root cause. However, some mitigating tricks are:
In /etc/rsyslog.d/02-rate_limit.conf
, i'm attempting the following
$SystemLogRateLimitInterval 5
$SystemLogRateLimitBurst 100
Also, a tweak is needed in /etc/rsyslog.conf
to avoid legacy vs new format confusion
#module(load="imuxsock") # provides support for local system logging
$ModLoad imuxsock
#module(load="imklog") # provides kernel logging support
$ModLoad imklog
Hopefully that will help throttle how quickly the bug can crash gnome (and the whole system if you don't have a separate /var/log)
Given this fork has the more recent commits, I assume it's more active and issues should be reported here? I reported the following in the other orangeshirt repo: Logging loop floods syslog