When testing server upgrades for bug 4885, I stumbled on the following backtrace when upgrading a 4.9.0 server or older to 4.13.0 or newer on DEB based systems (in my case Ubuntu 18.04 and 20.04): > ┌──── > │ ~/tl-4.14.0-server/ $ ./install-server > │ ... > │ Run ThinLinc Setup now [Yes/no]? y > │ > │ Traceback (most recent call last): > │ File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 18, in <module> > │ from thinlinc import sudorelaunch > │ File "/opt/thinlinc/modules/thinlinc/sudorelaunch.py", line 14, in <module> > │ import subprocess > │ ImportError: bad magic number in 'subprocess': b'\x03\xf3\r\n' > │ Error in sys.excepthook: > │ Traceback (most recent call last): > │ File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 72, in apport_excepthook > │ from apport.fileutils import likely_packaged, get_recent_crashes > │ File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5, in <module> > │ from apport.report import Report > │ File "/usr/lib/python3/dist-packages/apport/report.py", line 12, in <module> > │ import subprocess, tempfile, os.path, re, pwd, grp, os, time, io > │ ImportError: bad magic number in 'subprocess': b'\x03\xf3\r\n' > │ > │ Original exception was: > │ Traceback (most recent call last): > │ File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 18, in <module> > │ from thinlinc import sudorelaunch > │ File "/opt/thinlinc/modules/thinlinc/sudorelaunch.py", line 14, in <module> > │ import subprocess > │ ImportError: bad magic number in 'subprocess': b'\x03\xf3\r\n' > └──── This seems to stem from the assumption that Python 3 will not load `*.pyc' files outside `__pycache__' directories made in r37238 along with the following `*.pyc' file loading behavior: https://peps.python.org/pep-3147/#case-4-legacy-pyc-files-and-source-less-imports In version 4.9.0 or below, we shipped a local `/opt/thinlinc/modules/subprocess.py'. When imported, this file got a corresponding `subprocess.pyc' file. In 4.10.0 when the `subprocess.py' file got removed, we have a lone `subprocess.pyc' file for which "Case 4" in PEP3147 applies when using Python 3. Thus, unless explicitly removed (as was the case before r37238) a Python 3 ThinLinc server will attempt to load the `subprocess.pyc' file when trying to import the system-wide `subprocess' and crash with the above magic mismatch. Worth noting is that this `.pyc' loading behavior of Python 3 may have further similar consequences when upgrading even older versions as there has historically been more files residing at the top-level ThinLinc-specific `PYTHONPATH'. In other words, this may only be the tip of the iceberg if we consider upgrades from really old versions.
A fix has been implemented and all `/opt/thinlinc/modules/*.pyc' files will now be removed when installing server build #2540. Thus, `tl-setup' will now run as expected. Please note that the `*.pyc' will remain under `/opt/thinlinc/modules/Cheetah' and `/opt/thinlinc/modules/mountclient' when upgrading sufficiently old versions. Thus, if a module that we use will attempt to import `Cheetah' or `mountclient' we run the risk of encountering similar errors as the one described in comment 0. This, however, is pretty unlikely since neither `Cheetah' nor `mountclient' is shipped by Python. Thus, let's leave these, for now, to avoid complicating things. Tested by installing a 4.8.0 server (going through tl-setup) on Ubuntu 20.04 and starting a session. This was followed by upgrading the server to build #2540, going through tl-setup, and starting a session. The upgrade goes through just fine and sessions start up as expected. Marking as resolved.
Never mind. Forgot the release notes!
Release notes added!
Tested on Ubuntu 20.04 by installing 4.7.0 and then upgrading to 4.14.0. Saw the above crash, as expected. After upgrading to build 2550 everything worked nicely again. I compared which .pyc files we have on disk before and after the upgrade. As noted in comment 2, lots of stray files are still left around, but nothing in the top namespace. Only "Cheetah" and "thinlinc" packages continue having old files, which should hopefully be safe. Release notes look good, and the cleanup code added back looks very similar to the original from r37238, so it should be reliable. Also tested an upgrade on RHEL 7 to check for regressions, and everything worked fine there as well.