26 Jan
2024
26 Jan
'24
12:05 a.m.
Hi!
I noticed in the log files an error message from dbus concerning trinity's
kdesktop_lock:
dbus-daemon[692]: [system] Rejected: destination has a full message queue,
0 matched rules; type="signal", sender="(unset)" ((bus))
interface="org.freedesktop.DBus" member="NameOwnerChanged" error
name="(unset)" requested_reply="0"
destination="org.freedesktop.DBus"
(uid=1140 pid=1396 comm="/opt/trinity/bin/kdesktop_lock --internal 1394 ")
The error message keeps being repeated every few minutes. The following
processs is running:
ps aux | grep 1396
gianluca 1396 0.0 0.0
166644 0 ? S 2023 0:00 /opt/trinity/bin/kdesktop_lock --internal 1394
I am not using kdesktop_lock and what does it mean "--internal 1394"?
Is it safe to kill this process and would it then stop the error messages?
Thanks!
Gianluca
-----------------------------------------------------
Gianluca Interlandi, PhD gianluca(a)u.washington.edu
+1 (206) 685 4435
http://gianluca.today/
Department of Bioengineering
University of Washington, Seattle WA U.S.A.
-----------------------------------------------------
26 Jan
26 Jan
3:40 a.m.
Gianluca Interlandi via tde-users wrote:
I am not using kdesktop_lock and what does it mean
"--internal 1394"?
this is the process ID of the parent that started the kdesktop_lock process
Is it safe to kill this process and would it then stop
the error messages?
you can kill it yes - if it does not solve the problem, may be easiest way
is to reboot. The message is telling you that
destination="org.freedesktop.DBus" has a full message queue. This does not
exactly mean that this process filled up the queue.
You can use
dbus-monitor --system "interface=org.freedesktop.DBus"
to find out what is posting to this destination
6:19 a.m.
Killing the process kdesktop_lock stopped the messages. Right after
killing it the screen locked itself and I was able to unlock it with my
password.
If I type `dbus-monitor --system "interface=org.freedesktop.DBus"` I get
(before and after killing kdesktop_lock):
signal time=1706235347.842841 sender=org.freedesktop.DBus ->
destination=:1.6414 serial=2 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameAcquired
string ":1.6414"
signal time=1706235347.842896 sender=org.freedesktop.DBus ->
destination=:1.6414 serial=4 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameLost
string ":1.6414"
Not sure what this means. The error message may be related to hibernating.
I hibernate using `systemctl hibernate` and when I resume the screen is
not locked (which is what I prefer), but it could be that some process
wants to lock it?
Gianluca
On Fri, 26 Jan 2024, deloptes via tde-users wrote:
-----------------------------------------------------
Gianluca Interlandi, PhD gianluca(a)u.washington.edu
+1 (206) 685 4435
http://gianluca.today/
Department of Bioengineering
University of Washington, Seattle WA U.S.A.
-----------------------------------------------------
27 Jan
27 Jan
3:45 a.m.
Gianluca Interlandi via tde-users wrote:
Yes killing the kdesktop_lock locks the screen and the process is restarted
And those two messages you see are normal (the monitor also registers to the
dbus)
I forgot to mention
dbus-monitor --session "interface=org.freedesktop.DBus"
or
dbus-monitor --session "destination=org.freedesktop.DBus"
because I forgot that this interface is also available in the user session.
There are more messages to expect there - this is why I filter on interface
or destination, but if you do not see anything, you could simply use one of
those
dbus-monitor --session
or
dbus-monitor --system
4:43 a.m.
dbus-monitor --session (as user)
with or without any other arguments returns (same as yesterday):
signal time=1706316157.761804 sender=org.freedesktop.DBus ->
destination=:1.798 serial=2 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameAcquired
string ":1.798"
signal time=1706316157.762037 sender=org.freedesktop.DBus ->
destination=:1.798 serial=4 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameLost
string ":1.798"
However, it doesn't really bother me at this point. After killing the
process it did not return, even after hibernating and resuming.
Thanks,
Gianluca
On Sat, 27 Jan 2024, deloptes via tde-users wrote:
-----------------------------------------------------
Gianluca Interlandi, PhD gianluca(a)u.washington.edu
+1 (206) 685 4435
http://gianluca.today/
Department of Bioengineering
University of Washington, Seattle WA U.S.A.
-----------------------------------------------------
28 Jan
28 Jan
1:26 a.m.
Gianluca Interlandi via tde-users wrote:
However, it doesn't really bother me at this
point. After killing the
process it did not return, even after hibernating and resuming.
I have seen such errors, when I was playing with dbus and something filled
up the queue. It would have been interesting to know what did it on your
end.
434
days inactive
436
days old
5 comments
2 participants
participants (2)
-
deloptes -
Gianluca Interlandi