30 Apr
2023
30 Apr
'23
8:11 p.m.
I'm getting this strange situation again with DCOP:
| @22:01:36,leslie@pinto rc=0
| ~
| $ dcop --user leslie
| ERROR: Multiple available TDE sessions!
| Please specify the correct session to use with --session or use the
| --all-sessions option to broadcast to all sessions.
| @22:02:03,leslie@pinto rc=255
| ~
| $ dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
|
| @22:02:13,leslie@pinto rc=0
| ~
| $ px dcop
| leslie 26431 1 0 Apr29 ? 00:00:01 dcopserver [tdeinit] --nosid --suicide
| @22:02:20,leslie@pinto rc=0
| ~
| $ dcopserver --help-all
| Usage: dcopserver [--nofork] [--nosid] [--help]
| dcopserver --serverid
|
| DCOP is TDE's Desktop Communications Protocol. It is a lightweight IPC/RPC
| mechanism built on top of the X Consortium's Inter Client Exchange protocol.
| It enables desktop applications to communicate reliably with low overhead.
|
| Copyright (C) 1999-2001, The KDE Developers <http://www.kde.org>
For some reason DCOP says I have two DCOP sessions. .DCOPserver_pinto__0 does not
respond to queries, so apparently it's dead or a ghost. .DCOPserver_pinto__1 works
normally.
I notice also that the output from dcop --help does not include the --suicide option?
Is
this a clue to what's going on?
How do I get rid of the one that doesn't respond?
Leslie
--
Platform: Linux
Distribution: openSUSE Leap 15.4 (x86_64)
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
1 May
1 May
4:29 a.m.
Hello,
This DCOP problem after upgrade TDE R14.1.0 release ?
Cheers,
André
On Monday 01 May 2023 05:11:27 J Leslie Turriff via tde-users wrote:
I'm getting this strange situation again with
DCOP:
| $ dcop --user leslie
| ERROR: Multiple available TDE sessions!
| Please specify the correct session to use with --session or use the
| --all-sessions option to broadcast to all sessions.
| @22:02:03,leslie@pinto rc=255
| $ dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
| @22:02:13,leslie@pinto rc=0
| $ px dcop
| leslie 26431 1 0 Apr29 ? 00:00:01 dcopserver
| [tdeinit] --nosid --suicide
| @22:02:20,leslie@pinto rc=0
| $ dcopserver --help-all
| Usage: dcopserver [--nofork] [--nosid] [--help]
| dcopserver --serverid
| DCOP is TDE's Desktop Communications Protocol. It is a lightweight IPC/RPC
| mechanism built on top of the X Consortium's Inter Client Exchange
| protocol.
| It enables desktop applications to communicate reliably with low overhead.
| Copyright (C) 1999-2001, The KDE Developers <http://www.kde.org>
For some reason DCOP says I have two DCOP sessions. .DCOPserver_pinto__0
does not respond to queries, so apparently it's dead or
ghost. .DCOPserver_pinto__1 works normally.
I notice also that the output from dcop --help does not include the --suicide
option? Is this a clue to what's going on?
How do I get rid of the one that doesn't respond?
5 a.m.
On Sun, 30 Apr 2023 22:11:27 -0500
J Leslie Turriff via tde-users <users(a)trinitydesktop.org> wrote:
I'm getting this strange situation again with
DCOP:
| $ dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
For some reason DCOP says I have two DCOP sessions. .DCOPserver_pinto__0 does not
respond to queries, so apparently it's dead or a ghost. .DCOPserver_pinto__1 works
normally.
I notice also that the output from dcop --help does not include the --suicide option?
Is
this a clue to what's going on?
How do I get rid of the one that doesn't respond?
Why do you want to? The double session seems to be normal (I have it too), but
they appear to both be attached to the same process ( ps -ef | grep dcop returns
only one line). The --suicide option has to do with session termination in the
dcop server and won't show up in the help for the client. See
https://manpages.org/dcopserver .
Unless you have reason to think that the presence of the unresponsive session
has broken something, I would just leave this one alone. I don't think you're
going to get zombie sessions multiplying out of bounds or anything like that.
E. Liddell
3:30 p.m.
On 2023-05-01 07:00:26 E. Liddell via tde-users wrote:
On Sun, 30 Apr 2023 22:11:27 -0500
J Leslie Turriff via tde-users <users(a)trinitydesktop.org> wrote:
So, when scripting, how does one know which one to avoid? If
one picks the wrong one it
hangs the session.
I'm getting this strange situation again
with DCOP:
| $ dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
For some reason DCOP says I have two DCOP sessions.
.DCOPserver_pinto__0 does not respond to queries, so apparently it's dead
or a ghost. .DCOPserver_pinto__1 works normally.
I notice also that the output from dcop --help does not include the
--suicide option? Is this a clue to what's going on?
How do I get rid of the one that doesn't respond?
Why do you want to? The double session seems to be normal (I have it too),
but they appear to both be attached to the same process ( ps -ef | grep
dcop returns only one line). The --suicide option has to do with session
termination in the dcop server and won't show up in the help for the
client. See
https://manpages.org/dcopserver .
Unless you have reason to think that the presence of the unresponsive
session has broken something, I would just leave this one alone. I don't
think you're going to get zombie sessions multiplying out of bounds or
anything like that.
E. Liddell
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
3:51 p.m.
J Leslie Turriff via tde-users wrote:
So, when scripting, how does one know which one to
avoid? If one picks
the wrong one it hangs the session.
IF I am not completely mistaken the 0/1 is the screen (XServer port as
in :0)
it seems you created a session to screen 1 and it is a left over.
I wonder why you would want to use this file exactly, but if you insist, use
first dcop --list-sessions (if you want your user add --user <username>)
and then get the active session(s) from the list
4:04 p.m.
On 2023-05-01 17:51:06 deloptes via tde-users wrote:
J Leslie Turriff via tde-users wrote:
Of course; but
after --user <name> --list-sessions, if one sends a message to the one
that is non-responsive it will hang the session. How do I know which one that is without
hanging my session?
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
So, when scripting, how does one know which one
to avoid? If one picks
the wrong one it hangs the session.
IF I am not completely mistaken the 0/1 is the screen (XServer port as
in :0)
it seems you created a session to screen 1 and it is a left over.
I wonder why you would want to use this file exactly, but if you insist,
use first dcop --list-sessions (if you want your user add --user
<username>) and then get the active session(s) from the list
4:09 p.m.
On 2023-05-01 17:51:06 deloptes via tde-users wrote:
J Leslie Turriff via tde-users wrote:
Ah; so if I open
a konsole sesssion for one account from a different account I will get
another DCOP session, even if the "remote" account is not logged into Trinity?
How/why
would dcopserver be started in an account that is not logged in?
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
So, when scripting, how does one know which one
to avoid? If one picks
the wrong one it hangs the session.
IF I am not completely mistaken the 0/1 is the screen (XServer port as
in :0)
it seems you created a session to screen 1 and it is a left over.
4:40 p.m.
J Leslie Turriff via tde-users wrote:
Ah; so if I open a konsole sesssion for one account
from a different
account I will get another DCOP session, even if the "remote" account is
not logged into Trinity? How/why would dcopserver be started in an
account that is not logged in?
In your home directory it is written only what was created by or for the
user. I am not 100% sure, but the other user would have the same entry if
he/she is logged on screen 0, which I'm not sure is possible.
However the content of the file would be different.
Looking into it it is pointing to a socket, so that the applications can
talk to each other and it seems it uses ICE.
What remote account do you mean BTW? I think you are misunderstanding dcop.
AFAIK dcop is started by tdeinit to handle some interprocess communication,
so it is available only to users running TDE components that require this
kind of communication.
I do not know your use case, but it seems exotic.
5:50 p.m.
On 2023-05-01 18:40:57 deloptes via tde-users wrote:
J Leslie Turriff via tde-users wrote:
What is written?
Ah; so if I open a konsole sesssion for one
account from a different
account I will get another DCOP session, even if the "remote" account is
not logged into Trinity? How/why would dcopserver be started in an
account that is not logged in?
In your home directory it is written only what was created by or for the
user. I am not 100% sure, but the other user would have the
same entry if
he/she is logged on screen 0, which I'm not sure is possible.
However the content of the file would be different.
Looking into it it is pointing to a socket, so that the applications can
talk to each other and it seems it uses ICE.
What remote account do you mean BTW? I think you are misunderstanding dcop.
AFAIK dcop is started by tdeinit to handle some interprocess communication,
so it is available only to users running TDE components that require this
kind of communication.
That's what I thought, too, so where this extra session
is coming from is a mystery to
me.
I do not know your use case, but it seems exotic.
The use case is e.g. opening a
Root session in a user account's konsole, and a script run
by root wanting to get information about the konsole session. It would need to issue
these DCOP commands:
| ~
| ● dcop --all-users --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
|
| @19:37:24,root@pinto rc=0
the following fails to return; it would cause a script to hang:
| ~
| | ● dcop --user leslie --session .DCOPserver_pinto__0 'konsole*'
|
|
| ^C
| @19:39:39,root@pinto rc=130
| ~
| ● dcop --user leslie --session .DCOPserver_pinto__1 'konsole*'
| konsole-26491
| konsole-26485
| @19:41:55,root@pinto rc=0
| ~
| ● dcop --user leslie --session .DCOPserver_pinto__1 konsole-26491
| KBookmarkManager-/home/leslie/.trinity/share/apps/konsole/bookmarks.xml
| KBookmarkNotifier
| MainApplication-Interface
| konsole (default)
| konsole-mainwindow#1
| session-1
| session-2
| session-3
| session-4
| tdesycoca
| @19:43:02,root@pinto rc=0
| ~
| ● dcop --user leslie --session .DCOPserver_pinto__1 konsole-26491 session-3 sessionName
| /opt
| @19:44:23,root@pinto rc=0
| ~
| ● cd /opt
| @19:46:23,root@pinto rc=0
| /opt
| ●
So, how can I avoid having a script guess wrong about the session to query?
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
6:25 p.m.
On Mon, 1 May 2023 17:30:24 -0500
J Leslie Turriff via tde-users <users(a)trinitydesktop.org> wrote:
Scripting's a bit of an unusual use case. Does passing --all-sessions still result
in a hang? Is there a pattern to which session is unresponsive (always the
first, or always the second), or is it random?
I suppose you could fork off two instances of a simple test and see which
one exits and which hangs (and then kill the hanging one), but that's more
of a kludge than a solution . . .
E. Liddell
Unless you
have reason to think that the presence of the unresponsive
session has broken something, I would just leave this one alone. I don't
think you're going to get zombie sessions multiplying out of bounds or
anything like that.
So, when scripting, how does one know which one to avoid? If
one picks the wrong one it
hangs the session.
7:45 p.m.
On 2023-05-01 20:25:55 E. Liddell via tde-users wrote:
On Mon, 1 May 2023 17:30:24 -0500
J Leslie Turriff via tde-users <users(a)trinitydesktop.org> wrote:
Scripting's a bit of an unusual use case. Does passing --all-sessions
still result in a hang? Is there a pattern to which session is
unresponsive (always the first, or always the second), or is it random?
No, no.
--all-sessions always succeeds, but then there is no way to determine if one of
the sessions that it returns is dead or not, except by sending a message to each.
If I send a message to one that is dead the script will hang.
It would be nice if it returned a status code (or anything) instead of hanging.
Unless
you have reason to think that the presence of the unresponsive
session has broken something, I would just leave this one alone. I
don't think you're going to get zombie sessions multiplying out of
bounds or anything like that.
So, when scripting, how does one know which one to avoid? If one picks
the wrong one it hangs the session.
I suppose you could fork off two instances of a simple test and see which
one exits and which hangs (and then kill the hanging one), but that's more
of a kludge than a solution . . .
I agree.
E. Liddell
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
2 May
2 May
7:18 a.m.
On Monday 01 May 2023 09:45:16 pm J Leslie Turriff via tde-users wrote:
On 2023-05-01 20:25:55 E. Liddell via tde-users
wrote:
It's been since forever since I did anything with DCOP. If I read right up
thread you're doing this a root? So is there anyway to get the PID(s), check
which are zombies, then just kill them? Here's some commands to start with
(which you probably already know ;)
ps aux | grep -i dcop
ps aux | awk '$8 ~ /^[Zz]/'
^ last command blatently stolen from
https://itsfoss.com/kill-zombie-process-linux/
Best,
Michael
On Mon, 1 May 2023 17:30:24 -0500
No, no. --all-sessions always succeeds, but then there is no way to
determine if one of the sessions that it returns is dead or not, except by
sending a message to each. If I send a message to one that is dead the
script will hang.
It would be nice if it returned a status code (or anything) instead of
hanging.
7:45 a.m.
Michael via tde-users wrote:
It's been since forever since I did anything with
DCOP. If I read right
up thread you're doing this a root? So is there anyway to get the PID(s),
check which are zombies, then just kill them? Here's some commands to
start with (which you probably already know ;)
FYI the PID is written in the file, together with the socket.
11:02 a.m.
On 2023-05-02 09:18:14 Michael via tde-users wrote:
On Monday 01 May 2023 09:45:16 pm J Leslie Turriff via
tde-users wrote:
But there doesn't seem to be a zombie process associated with DCOP (or anything else,
really):
| ~
| ● ps aux | awk '$8 ~ /^[Zz]/'
| @12:52:29,root@pinto rc=0
| ~
| ● dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
|
| @12:52:45,root@pinto rc=0
so I'm wondering if the listed sessions are not produced just because of these files
(which I
suspect, based on the datestamp, are preserved across login/out sessions):
| ~
| $ la|grep DCOP
| lrwxrwxrwx 1 leslie users 33 2023-03-27
10:37:56 .DCOPserver_pinto_:0 -> /home/leslie/.DCOPserver_pinto__0
| -rw-r--r-- 1 leslie users 52 2023-03-27 10:37:56 .DCOPserver_pinto__0
| lrwxrwxrwx 1 leslie users 33 2023-04-29
15:53:26 .DCOPserver_pinto_:1 -> /home/leslie/.DCOPserver_pinto__1
| -rw-r--r-- 1 leslie users 54 2023-04-29 15:53:26 .DCOPserver_pinto__1
| @12:53:59,leslie@pinto rc=0
If I log out of my TDE session, then shell to /home/leslie and remove these files, maybe
that will clean up the issue? When I log back in via TDE, DCOP should recreate one of
them (presumably .DCOPserver_pinto__0)?
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
On 2023-05-01 20:25:55 E. Liddell via tde-users
wrote:
It's been since forever since I did anything with DCOP. If I read right up
thread you're doing this a root? So is there anyway to get the PID(s),
check which are zombies, then just kill them? Here's some commands to
start with (which you probably already know ;)
ps aux | grep -i dcop
ps aux | awk '$8 ~ /^[Zz]/'
^ last command blatently stolen from
https://itsfoss.com/kill-zombie-process-linux/
Best,
Michael
____________________________________________________
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
op.org On Mon, 1 May 2023 17:30:24 -0500
No, no. --all-sessions always succeeds, but then there is no way to
determine if one of the sessions that it returns is dead or not, except
by sending a message to each. If I send a message to one that is dead the
script will hang.
It would be nice if it returned a status code (or anything) instead of
hanging.
11:09 a.m.
On Tuesday 02 May 2023 01:02:01 pm J Leslie Turriff via tde-users wrote:
If I log out of my TDE session, then shell to
/home/leslie and remove
these files, maybe that will clean up the issue? When I log back in via
TDE, DCOP should recreate one of them (presumably .DCOPserver_pinto__0)?
Ah, don't delete them, just rename them. That way if it borks anything you
can put them back.
Best,
Michael
11:31 a.m.
On 2023-05-02 13:09:07 Michael via tde-users wrote:
On Tuesday 02 May 2023 01:02:01 pm J Leslie Turriff
via tde-users wrote:
You're right, of course.
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
If I log out of my TDE session, then shell to
/home/leslie and remove
these files, maybe that will clean up the issue? When I log back in via
TDE, DCOP should recreate one of them (presumably .DCOPserver_pinto__0)?
Ah, don't delete them, just rename them. That way if it borks anything you
can put them back.
Best,
Michael
7:36 p.m.
On 2023-05-02 13:02:01 J Leslie Turriff via tde-users wrote:
On 2023-05-02 09:18:14 Michael via tde-users wrote:
I renamed the .DCOPserver_pinto__* files and removed their links, and when I logged back
in dcop showed only one session. I'm guessing that dcop just echoes what it sees in
the
root directory without looking to see if there's actually a dcopserver with that pid
running.
Leslie
--
Platform: GNU/Linux
Hardware: x86_64
Distribution: openSUSE Leap 15.4
Desktop Environment: Trinity
Qt: 3.5.0
TDE: R14.0.13
tde-config: 1.0
On Monday 01 May 2023 09:45:16 pm J Leslie
Turriff via tde-users wrote:
But there doesn't seem to be a zombie process associated with DCOP (or
anything else,
really):
| ~
| ● ps aux | awk '$8 ~ /^[Zz]/'
| @12:52:29,root@pinto rc=0
| ~
| ● dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
|
| @12:52:45,root@pinto rc=0
so I'm wondering if the listed sessions are not produced just because of
these files (which I
suspect, based on the datestamp, are preserved across login/out sessions):
| ~
| $ la|grep DCOP
| lrwxrwxrwx 1 leslie users 33 2023-03-27
10:37:56 .DCOPserver_pinto_:0 -> /home/leslie/.DCOPserver_pinto__0
| -rw-r--r-- 1 leslie users 52 2023-03-27 10:37:56
| .DCOPserver_pinto__0 lrwxrwxrwx 1 leslie users 33 2023-04-29
15:53:26 .DCOPserver_pinto_:1 -> /home/leslie/.DCOPserver_pinto__1
| -rw-r--r-- 1 leslie users 54 2023-04-29 15:53:26
| .DCOPserver_pinto__1 @12:53:59,leslie@pinto rc=0
If I log out of my TDE session, then shell to /home/leslie and remove
these files, maybe that will clean up the issue? When I log back in via
TDE, DCOP should recreate one of them (presumably .DCOPserver_pinto__0)?
Leslie On 2023-05-01 20:25:55 E. Liddell via tde-users
wrote:
It's been since forever since I did anything with DCOP. If I read right
up thread you're doing this a root? So is there anyway to get the
PID(s), check which are zombies, then just kill them? Here's some
commands to start with (which you probably already know ;)
ps aux | grep -i dcop
ps aux | awk '$8 ~ /^[Zz]/'
^ last command blatently stolen from
https://itsfoss.com/kill-zombie-process-linux/
Best,
Michael
____________________________________________________
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@trinitydes
kt op.org On Mon, 1 May 2023 17:30:24 -0500
No, no. --all-sessions always succeeds, but then there is no way to
determine if one of the sessions that it returns is dead or not, except
by sending a message to each. If I send a message to one that is dead
the script will hang.
It would be nice if it returned a status code (or anything) instead of
hanging.
1 May
1 May
7:56 a.m.
On Sunday 30 April 2023 10:11:27 pm J Leslie Turriff via tde-users wrote:
I'm getting this strange situation again with
DCOP:
| $ dcop --user leslie --list-sessions
| Active sessions for user /home/leslie :
| .DCOPserver_pinto__0
| .DCOPserver_pinto__1
|
| @22:02:13,leslie@pinto rc=0
| ~
Sorta answering to both André and E. Liddell, I'm not having the issue:
michael@local [~]# head -1 /etc/os-release && inxi -S
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
System: Host: anon Kernel: 4.19.0-23-amd64 x86_64 bits: 64 Desktop: Trinity
R14.0.13
Distro: MX-19.4_x64 patito feo May 31 2020
michael@local [~]# dcop --user michael --list-sessions
Active sessions for user /home/michael :
.DCOPserver_anon__0
michael@local [~]#
So, yes?, it might be something with TDE R14.1.x?
HTH,
Michael
PS: I'll be on TDE R14.0.13 for awhile, tag me if anyone needs something run
as a comparison.
377
days inactive
379
days old
18 comments
5 participants
participants (5)
-
ajh-valmer -
deloptes -
E. Liddell -
J Leslie Turriff -
Michael