From berserker.troll at yandex.com Thu Nov 1 03:36:31 2018 From: berserker.troll at yandex.com (Troll Berserker) Date: Thu, 1 Nov 2018 04:36:31 +0100 Subject: [winswitch] Terminating Xpra does not terminate spawned Xorg until Xpra becomes ready Message-ID: <13085610-0826-f1e4-940a-fb2d05ec8846@yandex.com> Hi, I want to terminate Xpra if it didn't not become ready within some period of time. I've noticed that terminating Xpra (by sending SIGTERM or SIGINT) does not terminate the already spawned Xorg server. It wouldn't be a problem to kill the Xorg server if there were an easy way to get its PID from Xpra. But Xpra makes it more hard than necessary by using its main PID in the Xorg.log name instead of Xorg's PID. E.g. if Xpra is started with PID 300, it uses this PID in the Xorg.log file name even though the PID of the child where the Xorg is exec()d is 303. From antoine at nagafix.co.uk Thu Nov 1 07:53:41 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 1 Nov 2018 14:53:41 +0700 Subject: [winswitch] Terminating Xpra does not terminate spawned Xorg until Xpra becomes ready In-Reply-To: <13085610-0826-f1e4-940a-fb2d05ec8846@yandex.com> References: <13085610-0826-f1e4-940a-fb2d05ec8846@yandex.com> Message-ID: On 01/11/2018 10:36, Troll Berserker via shifter-users wrote: > Hi, > > I want to terminate Xpra if it didn't not become ready within some > period of time. > I've noticed that terminating Xpra (by sending SIGTERM or SIGINT) does > not terminate the already spawned Xorg server. It does, but there was a bug (not directly in xpra AFAICT) which caused the python cleanup hooks to fail to run, leaving the Xorg process alive. For more details, see: https://xpra.org/trac/ticket/1943 Just make sure that you're up to date and everything will work fine. > It wouldn't be a problem to kill the Xorg server if there were an easy > way to get its PID from Xpra. > But Xpra makes it more hard than necessary by using its main PID in the > Xorg.log name instead of Xorg's PID. > E.g. if Xpra is started with PID 300, it uses this PID in the Xorg.log > file name even though the PID of the child where the Xorg is exec()d is > 303. That's difficult to improve: the log filename is specified as an argument to the Xorg process. At that point, the new process ID is not known. In any case, the number you see is not the PID but the display number. Cheers, Antoine From berserker.troll at yandex.com Thu Nov 1 19:00:12 2018 From: berserker.troll at yandex.com (Troll Berserker) Date: Thu, 1 Nov 2018 20:00:12 +0100 Subject: [winswitch] Terminating Xpra does not terminate spawned Xorg until Xpra becomes ready In-Reply-To: References: <13085610-0826-f1e4-940a-fb2d05ec8846@yandex.com> Message-ID: <2344e4a4-fc86-f8d8-dbe6-0fe478ec224f@yandex.com> On 01/11/18 08:53, Antoine Martin via shifter-users wrote: > On 01/11/2018 10:36, Troll Berserker via shifter-users wrote: >> Hi, >> >> I want to terminate Xpra if it didn't not become ready within some >> period of time. >> I've noticed that terminating Xpra (by sending SIGTERM or SIGINT) does >> not terminate the already spawned Xorg server. > It does, but there was a bug (not directly in xpra AFAICT) which caused > the python cleanup hooks to fail to run, leaving the Xorg process alive. > > For more details, see: > https://xpra.org/trac/ticket/1943 > > Just make sure that you're up to date and everything will work fine. > Thank you, but I use Xpra 2.4.1 with this fix incorporated. Prolly I was not clear enough. Xorg gets killed if it assigns display number. But if I kill the main process between Xorg start and display assignment, the Xorg process is not killed. I've looked at https://xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/server.py?rev=20254#L774 and https://xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/server.py?rev=20254#L818 and I see why this happens. The `kill_display` cleanup function is added to the list of cleanups only after the function `start_Xvfb` returns. And it does not return until the display number is assigned. Possible fix? Instead of returning the list of `cleanups` from the `start_Xvfb`, pass the `add_cleanup` callback and add cleanups ASAP. Also, move the code from https://xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/server.py?rev=20254#L818 to the `start_Xvfb`, immediately after the `subprocess.Popen`. >> It wouldn't be a problem to kill the Xorg server if there were an easy >> way to get its PID from Xpra. >> But Xpra makes it more hard than necessary by using its main PID in the >> Xorg.log name instead of Xorg's PID. >> E.g. if Xpra is started with PID 300, it uses this PID in the Xorg.log >> file name even though the PID of the child where the Xorg is exec()d is >> 303. > That's difficult to improve: the log filename is specified as an > argument to the Xorg process. At that point, the new process ID is not > known. > `subprocess.Popen` has the `preexec_fn` param, which you are using. It is called after the fork, when the child PID is already known. Isn't it possible to modify `xvfb_cmd` in the `preexec` function? From antoine at nagafix.co.uk Fri Nov 23 12:36:40 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Nov 2018 19:36:40 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.4.2: important fixes Message-ID: <0edaa4e8-55e6-9a34-592a-525f835a912a@nagafix.co.uk> Hi, This update fixes a number of important bugs, including server crashes and client hangs. Updating is strongly recommended but none of those bugs are new so there is no urgency to update if you were not affected by those issues. Release notes: * fix server crash with application setting invalid X11 atoms * fix missing windows with some mono applications (ignore invalid atoms) * fix small X11 memory leak * fix encoding of empty areas (hard to trigger) * fix client hangs due to signal-watcher (now disabled with python2) * fix virtual printer cleanup errors * fix leaking xvfb processes when displayfd times out * fix window size hints not being sanitized correctly * fix cpu waste and automatic quality calculations * fix statistics used by shadow servers * fix error capturing screenshots on MS Windows * fix logging error in modifier state change failure code path * fix nvenc errors with odd image heights * fix over aggressive screen update rectangle merging * fix race condition causing the connection cleanup code to run twice * fix ssh dialog button actions * ensure Qt applications use the X11 backend so we can intercept them * skip unnecessary video tests when mmap is enabled * handle property change handlers errors more gracefully * avoid recycling video contexts unnecessarily * don't flush video encoders when doing a regular content refresh The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From thomas.mainka at gmail.com Fri Nov 23 12:13:25 2018 From: thomas.mainka at gmail.com (Thomas Mainka) Date: Fri, 23 Nov 2018 13:13:25 +0100 Subject: [winswitch] RHEL 6/Xpra 1.x - Problems with python2-pillow Message-ID: Hello, for some reason after an upgrade to Xpra on RHEL 6 went a bit flakey, sometimes displaying white/black windows. From digging around in the log files there seems to be an unmet dependency in the python2-pillow-4.3.0-1.el6_10.x86_64.rpm package that gets installed: Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/xpra/server/source.py", line 1687, in do_send_cursor from PIL import Image File "/usr/lib64/python2.6/site-packages/PIL/Image.py", line 56, in from . import _imaging as core ImportError: /usr/lib64/python2.6/site-packages/PIL/_imaging.so: undefined symbol: PyCapsule_New PyCapsules are a Python 2.7 thing, while the Python on RHEL 6 is still 2.6.6 - am I missing something, or is Xpra on EL6 supposed to run with a different Python version? Regards, Thomas From antoine at nagafix.co.uk Fri Nov 23 12:49:08 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Nov 2018 19:49:08 +0700 Subject: [winswitch] RHEL 6/Xpra 1.x - Problems with python2-pillow In-Reply-To: References: Message-ID: On 23/11/2018 19:13, Thomas Mainka via shifter-users wrote: > Hello, > > > for some reason after an upgrade to Xpra on RHEL 6 went a bit flakey, > sometimes displaying white/black windows. From digging around in the > log files there seems to be an unmet dependency in the > python2-pillow-4.3.0-1.el6_10.x86_64.rpm package that gets installed: > > Traceback (most recent call last): > File "/usr/lib64/python2.6/site-packages/xpra/server/source.py", > line 1687, in do_send_cursor > from PIL import Image > File "/usr/lib64/python2.6/site-packages/PIL/Image.py", line 56, in > from . import _imaging as core > ImportError: /usr/lib64/python2.6/site-packages/PIL/_imaging.so: > undefined symbol: PyCapsule_New > > PyCapsules are a Python 2.7 thing, while the Python on RHEL 6 is still > 2.6.6 - am I missing something, or is Xpra on EL6 supposed to run with > a different Python version? That's odd, but it does ring a bell. Can you try downgrading python-pillow to version 3.4.2 to see if that fixes it? Thanks, Antoine From antoine at nagafix.co.uk Fri Nov 23 12:57:08 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Nov 2018 19:57:08 +0700 Subject: [winswitch] RHEL 6/Xpra 1.x - Problems with python2-pillow In-Reply-To: References: Message-ID: <9a69e175-02db-e4bd-d5b6-c796afb4d98a@nagafix.co.uk> On 23/11/2018 19:49, Antoine Martin via shifter-users wrote: > On 23/11/2018 19:13, Thomas Mainka via shifter-users wrote: >> Hello, >> >> >> for some reason after an upgrade to Xpra on RHEL 6 went a bit flakey, >> sometimes displaying white/black windows. From digging around in the >> log files there seems to be an unmet dependency in the >> python2-pillow-4.3.0-1.el6_10.x86_64.rpm package that gets installed: >> >> Traceback (most recent call last): >> File "/usr/lib64/python2.6/site-packages/xpra/server/source.py", >> line 1687, in do_send_cursor >> from PIL import Image >> File "/usr/lib64/python2.6/site-packages/PIL/Image.py", line 56, in >> from . import _imaging as core >> ImportError: /usr/lib64/python2.6/site-packages/PIL/_imaging.so: >> undefined symbol: PyCapsule_New >> >> PyCapsules are a Python 2.7 thing, while the Python on RHEL 6 is still >> 2.6.6 - am I missing something, or is Xpra on EL6 supposed to run with >> a different Python version? > That's odd, but it does ring a bell. > Can you try downgrading python-pillow to version 3.4.2 to see if that > fixes it? In fact, you should not have installed 4.3.0 as it was not in the CentOS 6.10 repository metadata, only in the download folder. And the reason for that is that although the package does build OK, it does not run, as you found out. Cheers, Antoine From thomas.mainka at gmail.com Mon Nov 26 10:08:11 2018 From: thomas.mainka at gmail.com (Thomas Mainka) Date: Mon, 26 Nov 2018 11:08:11 +0100 Subject: [winswitch] RHEL 6/Xpra 1.x - Problems with python2-pillow In-Reply-To: <9a69e175-02db-e4bd-d5b6-c796afb4d98a@nagafix.co.uk> References: <9a69e175-02db-e4bd-d5b6-c796afb4d98a@nagafix.co.uk> Message-ID: Hi, On Fri, Nov 23, 2018 at 1:57 PM Antoine Martin via shifter-users wrote: > In fact, you should not have installed 4.3.0 as it was not in the CentOS > 6.10 repository metadata, only in the download folder. > > And the reason for that is that although the package does build OK, it > does not run, as you found out. indeed I have mirrored the repository locally and installed from there, which installed the new version. Since downgrading to the old python2-pillow-3.4.2-1.el6_10.x86_64.rpm package Xpra works fine. Regards, Thomas