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
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?
On Sun, 30 Apr 2023 22:11:27 -0500 J Leslie Turriff via tde-users users@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
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@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.
So, when scripting, how does one know which one to avoid? If one picks the wrong one it hangs the session.
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
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
On 2023-05-01 17:51:06 deloptes via tde-users wrote:
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
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
On 2023-05-01 17:51:06 deloptes via tde-users wrote:
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.
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
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.
On 2023-05-01 18:40:57 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?
In your home directory it is written only what was created by or for the user.
What is written?
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
On Mon, 1 May 2023 17:30:24 -0500 J Leslie Turriff via tde-users users@trinitydesktop.org wrote:
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.
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
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@trinitydesktop.org wrote:
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.
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.
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
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:
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.
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
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.
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:
On 2023-05-01 20:25:55 E. Liddell via tde-users wrote:
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.
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@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt op.org
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 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
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:
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
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
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:
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:
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.
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@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydes kt op.org
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
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
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.
-
ajh-valmer -
deloptes -
E. Liddell -
J Leslie Turriff -
Michael