Unable to access server via WSGI

[pu15e]

We have a Python API which runs both on a console and via WSGI...

On Ubuntu 20.04, this was not a problem.

Upon moving the system to Ubuntu 22.04, libtmux can no longer use the tmux server via WSGI, while it's working fine on a console (same app).

We were originally using Apache's mod-wsgi which, as stated, worked on 20.04 but then wouldn't on 22.04. We've since moved to Gunicorn but the same problem exists: after doing tmux = libtmux.Server(), tmux returns Server(socket_path=/tmp/tmux-1000/default) yet tmux.is_alive() returns False and, of course, no sessions are found.

Aside from the move to Ubuntu 22.04, everything (including the tmux socket permissions, etc) is identical to the working setup on 20.04.

Ideas?

[tony]

• Is it fine to move this to Q&A discussions? (it would close this thread but move it to a Question format)

While I can't give support, some troubleshooting ideas:

• Whether wsgi is involved is probably not relevant

  Between Ubuntu 20.04 and 22.04, the tmux version may have shifted

  • tmux version: tmux -V?

  • if you're using ubuntu's package, went from 3.0a to 3.2a (via here: focal 20.04LTS, jammy 22.04LTS)

• libtmux version?: e.g. pip show libtmux

Through the wsgi application, try subprocess.run and see how subprocess.run(['tmux', 'list-sessions']) reacts. If that was in the code where libtmux normally is, it will be the most barebones way see what tmux itself is doing based on the app's environmental conditions.

Guess / shot in the dark: it may be that either the tmux server isn't alive while the app is running (but the console is automatically creating a server while you use it, and persisting it since a client is attached). It may be needed to initialize a server via libtmux, e.g.

if not server.is_alive():
    server.new_session()

[pu15e]

Hey Tony :-)

Yup - they are the exact two tmux versions involved (3.0a and 3.2a).

tmux 3.3 adds an -a (user access) switch, but the tmux changelog between the mentioned versions shows nothing that's relevant.

libtmux was 0.21.1 on the old host, and 0.23.2 is on the new one. I've stepped back through every version to 0.21.1 in the course of troubleshooting.

Will try subprocess.run() shortly, but see next...

I should have been clearer about the fact that I meant the app runs in the console and via wsgi simultaneously. And that, by the time either instance is fired, systemd and a bash script have already created the server and session (and runs the python app in a tmux window) after which the python app attaches to the session and further fires up around 80 processes, which each get a tmux window. Then I generally attach to the session myself in an ssh terminal and interact with the python process in one of the tmux windows. So the server and session are definitely running the entire time :-)

I don't expect you to provide support, but am very appreciative that you're doing so anyways. I've been on this for several days now, and been rather thorough / extensive, to no avail. Something has changed somewhere, but I just can't pick it...

[pu15e]

Soooo, your suggestion (subsystem.run()) led me to finding the problem and thus the solution...

In the systemd unit file for gunicorn, we had set PATH as an env var. And only included the venv's bin/ folder.

Adding /usr/bin fixed it.

Doesn't explain why moving the apache / wsgi config file across from the old host also exhibited the same problem, but we were always gonna shift to nginx / gunicorn anyways, so all's well that ends well :-)

Thanks soooo much for your time and help. You're a champ!!

[tony]

Good it got figured out, thanks for the explanation as well, other's may find that handy.