X2Go Bug report logs -
#541
Patch to close Bug #525 has undesirable side effects
Reported by: Stefan Baur <newsgroups.mail2@stefanbaur.de>
Date: Tue, 8 Jul 2014 22:20:02 UTC
Severity: grave
Found in version 4.0.2.1
Done: Stefan Baur <X2Go-ML-1@baur-itcs.de>
Bug is archived. No further changes may be made.
Full log
🔗
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
This is an automatic notification regarding your Bug report
which was filed against the x2goclient package:
#541: Patch to close Bug #525 has undesirable side effects
It has been closed by Stefan Baur <X2Go-ML-1@baur-itcs.de>.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Stefan Baur <X2Go-ML-1@baur-itcs.de> by
replying to this email.
--
X2Go Bug Tracking System
Contact owner@bugs.x2go.org with problems
[Message part 2 (message/rfc822, inline)]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
close 541
thanks
- --
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUrqHWAAoJEG7d9BjNvlEZPY0IAJfRrBIKtnMbDcm02eSNM6KO
AE29vjbYerZZ5t3M1A8i6Nifl5P3FLoqFFh/PFt9bvXFiDTo4v4kBgQrdLe0PzVG
aCEIUh/EXqzFjBk5UcC9E92XaASAP3hjeKaShocygMbg/RV9LOrqdLD/gPJknUz3
gkka5+vxKWY/633V2S7A2lSce52cZBO0vZd+VDJSPTuYOK6gWZJs2jpGsj2Apjrp
zhHOjj/51KV9FyDLze+gYoGhHomF5RfAXPtM/Qe8p+YjJwBN2aDWcUJwSXQzjlTi
3lqz2pY29DpVA0M+9UW3RoSwDHCgSoPrLorJDcedVCq3KOL0P/Pb+lLDcT+ux7I=
=2I+7
-----END PGP SIGNATURE-----
[Message part 3 (message/rfc822, inline)]
Package: x2goclient
Version: 4.0.2.1
Severity: grave
Hi,
Alex' latest patches introduce a new and more severe bug.
His idea, assuming that Mike#1. Mike#2, Mihai and me understood him correctly, is, that on Windows, users shouldn't start x2goclient.exe any more, but rather the new x2gohelper.exe.
==>Alex, if we're misunderstanding what you wrote, please reply and explain your intentions.
Assuming we're right, your plan breaks backward compatibility when it comes to desktop shortcuts on Windows, in two places.
The smaller issue is that clicking the arrow on the session tile will create a desktop shortcut that is hardcoded to x2goclient.exe instead of x2gohelper.exe.
This could be fixed with a small patch. However ...
The bigger issue is that *all* existing links users may have on their desktops are broken, since they point to x2goclient.exe and can't easily be changed!
I have at least one customer that makes heavy use of that feature, where it would mean manually updating over 600 desktop shortcuts. That is not going to be fun!
We need to find a way to achieve what you were trying to achieve without breaking backward compatibility like that.
From what I understand so far, you're trying to build a "reaper" to clean up after a dying x2golient.exe, which may have left pulseaudio, xserver and ssh daemon running.
I haven't tried to figure out what your current x2gohelper.exe is trying to do, and if you made changes to x2goclient.exe as well where functionality from x2goclient.exe is moved to x2gohelper.exe. If you moved it, rather than duplicating it, that's not going to help, because it might just as well be x2gohelper.exe that dies first and you'd again leave sshd, pulseaudio, and xserver dangling.
Duplicating it might work, similar to how certain malware on Windows works (two processes checking on each other and re-spawning whichever gets killed first).
So you'd have x2goclient.exe on the one hand permanently checking if x2gohelper.exe is running, respawning it when necessary, and upon shutdown, "trying" to clean up behind itself by terminating sshd, pulseaudio, xserver, and finally itself. While x2gohelper.exe would be checking if x2goclient.exe is still running - if not, it will terminate sshd, pulseaudio, xserver, (if any of them are still running) and finally itself.
Before you start coding, I'd like to ask this question, though:
Do we really want to have a reaper mechanism that tries to clean up after a malfunctioning x2goclient.exe, or wouldn't it be better to find out why x2goclient.exe is malfunctioning, fix these issues / catch those exceptions and deal with them appropriately (i.e. properly shutting down sshd, pulseaudio and xserver before going belly-up)? The latter would mean we need more bug reports and it requires analyzing what exactly went wrong, but it would be less disturbing to x2goclient development and roll-out.
Whichever path you choose, Alex, please do keep in mind that we have a release planned in the near future and your latest commits aren't exactly helpful in getting 4.0.2.1 stabilized (and I *need* 4.0.2.1 out soon, my customers are desperately waiting for it because of the improved sound that PA5 brings).
It would be really really cool if you could either do your development on a separate branch that could later become 4.0.2.2, or hold back until we have released 4.0.2.1.
If you don't know how to do create your own branch for development, I'm sure there is more than just one Dev on the list that will help you.
Kind Regards,
Stefan
Send a report that this bug log contains spam.
X2Go Developers <owner@bugs.x2go.org>.
Last modified:
Sun Nov 24 08:15:50 2024;
Machine Name:
ymir.das-netzwerkteam.de
X2Go Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.