Thanks for the hints on it . . . likely won’t have time for the day or next few days, but when I get the chance to play with it I’ll see if anything relevant shows up . . . OR pop back with some more questions. Seems like the older Leap install is more flagrant in its misbehaviors than the new one . . . to be continued.
Today is Leap 16 day . . . running a zypper up I saw a few of these “typelib” packages to be upgraded or installed . . . would that relate to “typing” of words?
typelib-1_0-Gio-2_0 typelib-1_0-GLib-2_0 typelib-1_0-GModule-2_0
typelib-1_0-GObject-2_0 ucode-amd udisks2 udisks2-bash-completion udisks2-lang
xkbcomp
The following NEW package is going to be installed:
typelib-1_0-GExiv2-0_10
73 packages to upgrade, 1 new.
In a word. No.
[sfalken@mustang ~]$ zypper info typelib-1_0-Gio-2_0
Loading repository data...
Reading installed packages...
Information for package typelib-1_0-Gio-2_0:
--------------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : typelib-1_0-Gio-2_0
Version : 2.86.3-3.1
Arch : x86_64
Vendor : openSUSE
Installed Size : 365.8 KiB
Installed : Yes (automatically)
Status : out-of-date (version 2.86.3-2.1 installed)
Source package : glib2-2.86.3-3.1.src
Upstream URL : https://gitlab.gnome.org/GNOME/glib/
Summary : Object-Oriented Framework for C
Description :
GLib is a general-purpose utility library, which provides many useful
data types, macros, type conversions, string utilities, file utilities,
a main loop abstraction, and so on.
The GObject library provides an object-oriented framework for C.
Just as an example of what typelib packages are.
A quick web search on what a typelib is, gives me the following description:
GLib typelibs are collections of type definitions and functions that allow programming languages, like Perl or Haskell, to interact with the GLib library, which provides essential data structures and utilities for software development. They enable developers to use GLib's features in their applications without needing to write C code directly.
Which is a reasonable enough description, for a high level overview.
1 Like
OK, today was “Leap 16” day, so I did my daily driving, and no surprises couldn’t promote the egregious behaviors thus far . . . . I did open two tabs in the Terminal and ran those two suggested commands, had to use “sudo” to get the first one to run, and then they showed almost identical information . . . but no errors reported and so far, no errors in mouse and typing happened today. Other than difficulty getting the mouse cursor to change to the “drag the edge” of the window, still needs multiple passes back and forth over the edge of the window to drag it larger, and very difficult to catch the “corner” to drag two sides at one time . . . . Have to drag down, and then move over to the side and drag it sideways . . . . Which does seem “exclusive” to the 16 install of XFCE . . . .
And where is (at least) a snippet of the output of those commands from during the erronious behaviour ?
No, the first was to be run as user (no sudo) - specifically…
journaltctl --user -f
This was to see if any desktop session-related errors desktop/session-level issues evident (window manager, panels, portals, input methods, etc).
The second run with root privileges (for system journal output)…
sudo journalctl -f
This was for system-level messages (Xorg, libinput, kernel input drivers, GPU/DRM), which might help identify where some keyboard or focus issues etc.
I did note the differences in the commands, but running the first one said something like “inadequate privileges to do this request,” so I assumed that meant it needed “sudo” . . . which then the results were more or less the same . . . no “red flags.”
But, then, I couldn’t get the problem to show up . . . let alone while the commands were running . . . . I’ll try it again at some point . . . .
You should post the command you typed and the output returned. Running "journalctl --user "is for viewing user-specific session logs. No sudo required.
For example:
~> journalctl --user -f
Feb 06 09:34:17 dell-laptop firefox[161960]: Error writing selection data: Error writing to file descriptor: Broken pipe
Feb 06 09:34:17 dell-laptop firefox[161960]: Error writing selection data: Error writing to file descriptor: Broken pipe
Feb 06 09:34:17 dell-laptop firefox[161960]: Error writing selection data: Error writing to file descriptor: Broken pipe
Feb 06 10:02:21 dell-laptop plasmashell[161750]: DataControlOffer: timeout reading from pipe for mimeType SAVE_TARGETS
Feb 06 10:04:04 dell-laptop plasmashell[161750]: DataControlOffer: timeout reading from pipe for mimeType text/plain;charset=utf-8
Feb 06 10:04:05 dell-laptop plasmashell[161750]: DataControlOffer: timeout reading from pipe for mimeType text/plain
~> journalctl --user -f
Hint: You are currently not seeing messages from the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
No journal files were opened due to insufficient permissions.
This is likely what was shown the previous time, rushing though my day, I just saw the “insufficient permissions” . . . and thought that meant it needed sudo . . . . My eyes must have glazed over the “pass -q to turn off notice,” but even if I saw it had no idea where I would “pass that ‘-q’” to . . . .
Add your user to the “systemd-journal” group and no need for sudo.
usermod -a -G systemd-journal YOUR_USERNAME then logout/login
1 Like
OK . . . seems like the system wanted “root” or possibly “sudo” to run that through. Now it shows:
:~> journalctl --user -f
No journal files were found.
@non_space no idea, works here journalctl --user -f produces output… just wait and see if something appears, else just run journalctl -f as it will follow everything. You did logout/login and confirm your users is in the systemd-journal by running groups?
I have been doing stuff on the web and so far the journal data is the same . . . static.
~> groups
users systemd-journal
OK, just going with -f now shows movement:
:~> journalctl -f
Feb 05 17:24:42 localhost.localdomain NetworkManager[1149]: <info> [1770341082.4776] dhcp4 (eth0): state changed new lease, address=192.168.4.99
Feb 05 17:24:42 localhost.localdomain systemd[1]: Starting Network Manager Script Dispatcher Service...
Feb 05 17:24:42 localhost.localdomain systemd[1]: Started Network Manager Script Dispatcher Service.
Feb 05 17:24:42 localhost.localdomain dns-dnsmasq.sh[9069]: <debug> NETWORKMANAGER_DNS_FORWARDER is not set to "dnsmasq" in /etc/sysconfig/network/config -> exit
Feb 05 17:24:52 localhost.localdomain systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Feb 05 17:28:38 localhost.localdomain rtkit-daemon[2464]: Successfully made thread 9397 of process 8780 owned by '1000' RT at priority 10.
Feb 05 17:34:22 localhost.localdomain systemd[1]: Starting Backup RPM database...
Feb 05 17:34:34 localhost.localdomain systemd[1]: backup-rpmdb.service: Deactivated successfully.
Feb 05 17:34:34 localhost.localdomain systemd[1]: Finished Backup RPM database.
Feb 05 17:34:34 localhost.localdomain systemd[1]: backup-rpmdb.service: Consumed 11.364s CPU time.
and then this:
Feb 05 17:51:27 localhost.localdomain rtkit-daemon[2464]: Successfully made thread 11628 of process 11457 owned by '1000' RT at priority 10.
Feb 05 17:51:27 localhost.localdomain systemd[2293]: Starting Xfce configuration service...
Feb 05 17:51:27 localhost.localdomain systemd[2293]: Started Xfce configuration service.
The last messages are system messages - nothing unusual/problematic there.
Indeed, that is what I had posted above . . . “it looks normal.” What I didn’t realize is how the data doesn’t load quickly, like the dmesg data does . . . .
I don’t know if a recent zypper up has resolved the problem . . . or, more possibly it has gone back to “intermittent” behavior. But, this wasn’t a “It happened one time and I posted a thread about it.” It occurred in increasing frequency over a month or so . . . .
Anyway . . . still “monitoring” it . . . .
Run journalctl -b --no-pager then… The -f is for follow, so only show messages from now, FYI dmesg is restricted to root user these days, hence adding your user to the journal group gives much better access…
1 Like
So running that command must have brought in over 1000 lines?? As the system has “scrollback” set at 1000 lines and I couldn’t scroll up to the command in the data??
Only one line showed “failure” . . . .
Feb 07 10:39:58 localhost.localdomain accounts-daemon[1317]: g_dbus_interface_skeleton_get_object_path: assertion 'G_IS_DBUS_INTERFACE_SKELETON (interface_)' failed
There were a few errors of one type or another on “IRQ” and not sure, perhaps other “dbus” . . . and then cursor returned . . . so it’s not “monitoring” the system . . . . Seems like a huge amount of data to post that isn’t clearly showing something is urgently busted down and broke??
That’s expected behaviour, so nothing to worry about there. The journalctl command just shows what’s already being logged in the systemd journal, and a normal desktop session can easily generate hundreds or thousands of lines very quickly. The terminal scrollback limit is why the command itself scrolled out of view. The key thing is whether any new messages appear at the exact moment the glitch happens.
This message is of no relevance to the input or rendering glitchy issue you describe.
Th reason I requested/prefer the journalctl -f type approach is that command just follows the output until you interrupt it (Ctrl-C). This limits the need to trawl or post through lengthy logs.
Occasional IRQ-related messages can be normal unless they repeat rapidly or coincide exactly with the problem.
1 Like
So far, for the second “week” on Leap 16 since reporting the problem, it has not replicated, so perhaps a glitchy package was zyppered out??
But running the “sudo journalctl -f” shows a section of the “IRQ” data that I believe showed previously. The “journalctl --user -f” still shows “no files found”???
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 83 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 83 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 45 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 45 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 53 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 53 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 43 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 43 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 51 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 51 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 41 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 41 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 48 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 48 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 46 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 46 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 54 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 54 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 44 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 44 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 52 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 52 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 42 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 42 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 40 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 40 affinity is now unmanaged
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: Cannot change IRQ 49 affinity: Permission denied
Feb 11 08:54:35 localhost.localdomain irqbalance[1004]: IRQ 49 affinity is now unmanaged
Feb 11 08:54:38 localhost.localdomain PackageKit[8791]: daemon quit
@non_space User @pallaswept has info on this…
1 Like