25 Jan
2024
25 Jan
'24
8:05 p.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.
-----------------------------------------------------
25 Jan
25 Jan
11:40 p.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
26 Jan
26 Jan
2: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 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.
-----------------------------------------------------
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
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
11:45 p.m.
Gianluca Interlandi via tde-users wrote:
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?
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
27 Jan
27 Jan
12: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 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.
-----------------------------------------------------
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?
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
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
9:26 p.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.
456
days inactive
458
days old
5 comments
2 participants
participants (2)
-
deloptes -
Gianluca Interlandi