On Thu, 5 Dec 2024 19:33:40 -0500, bent fender <slowroller@trixtar.org> wrote:
Thu, 5 Dec 2024 23:23:02 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Thu, 5 Dec 2024 08:21:55 -0500, bent fender <slowroller@trixtar.org> wrote:
Thu, 5 Dec 2024 11:27:58 +0100 "Carlos E. R." <robin.listas@telefonica.net> :
On 2024-12-05 03:07, bent fender wrote:
The way it was being called: bash my-xeyes-launch.bsh
I believe the script is being called also from some other piece of software besides the above line in your ~/.profile . To enable easy current and future debugging, I suggest replacing the line with:
if [ -e ~/.profile-disable_xeyes_launch ] ;then echo === .profile xeyes disabled: ~/.profile-disable_xeyes_launch >&2 else sh my-xeyes-launch.bsh fi
Sounds like a good idea BUT, would this not nix the second execution which happens to be the one I'd want to keep? In a similar attack I would want to kill the first instance because that is the one that plays out on a lo-res screen later to occupy only the left half of its hi-res successor with its right edge eyeballs now in the middle. So instead of preventing a 2nd execution how would I terminate the first instance using the same srcipt?
Which one is the first one, though? Maybe it is the one in .profile . Getting the known one out of the way will help you find the other one, besides proving that it exists.
I can no longer duplicate the jinx however, it always started on the initially lo-res screen with the previous card. That lo-res screen no longer appears at all. I 'could' recover the old image and use the old card but I think I'll pass :-)
[...]
I'll try this just to see if the bug is still lurking, as it probably is. It's probably still executing twice but the second iteration just covers the first one since n=both arise on a hi-res screen.
Seems possible.
I inserted those lines into ~/.profile, logging in produced a 0 byte file ~/.profile-disable_xeyes_launch and the touch command against it returned nothing (what iis it supposed to do?).
The touch command creates the (empty) file, if it does not already exist. If it exists, then the modification time is updated to now. There is no output from the command. Logging in should not create that file, it should only read its directory entry. The touch command should not be in .profile . Use it manually when you want to disable one set of xeyes instances on following logins (for debugging).
[...] Then I figured what if I leave the file there, that should prevent the execution of the first xeyes command as well on the next log-in because the file exists. It didn't. This is a litlle over my head.
So the xeyes are still there. It probably did disable one set. Leave the "disable" file there and now it's time to look for where the other xeyes set is started from. Add this to your 'my-xeyes-launch.bsh' script, to capture its caller and parent, to the journal: logger -t xeyesLaunch -i -- "[$$]($(ps -q $$ -o args=)) ppid [$PPID]($(ps -q $PPID -o args=))" After logging in, view the messages with: journalctl -t xeyesLaunch -b You should check your KDE Autostart configuration to see whether the script is in there in addition to being called from ~/.profile . -- Robert Webb