1

I am using a tmux session to run a script that runs some Python code (which uses a virtual environment stored at /opts/...; Python binaries have been copied not linked) that creates virtual machines using libvirt. When I run virsh list --all inside of this tmux session when the script has finished, the machines do not show up. When I run sudo virsh list --all they show up. When I leave the session virsh list --all shows me the VMs as expected. I get them listed as expected as well in a subsequently created new tmux session. What is happening and how can I fix this?

If I run the script outside tmux, then listing the virtual machines works with virsh list --all.

Improve this question

1 Answer 1

Reset to default
0

I do not know it if this fixes your problem. However following solved mine:

  • Stop all tmux sessions.
    • Really all, such that no tmux runs anymore on the machine
  • Logout
  • Login again
  • Start a fresh tmux

Now virsh list --all works within tmux as expected.

At my side the problem was, that my user was added to group libvirt after I started tmux. Hence all sessions within tmux, even the brand new ones, did not have group libvirt yet.

This is a tmux annoyance, as even brand new tmux invocations still are started by the same old tmux server (they could be started by the current tmux and then being handed over to the server by FD-passing via Unix sockets, but this is not how tmux works, sigh), such that everything dies with this server, too (I'd like to see that the tty is held by both, the server and each client tmux, such that if either dies nothing really bad happens).

And the tmux server crashes far too frequently: 1 time a year means 3 times a day when running tmux on 1000 VMs. Even if it crashes with a probability as low as 10^-20 (tmux' crash probability is higher), this still means far too frequent crashes, as each computer runs - at least these days - 10^10 instructions per second, which roughly means, 1 crash every 350 years.

With rounded down estimate of 100 billion computing units out there and 5$ worth of lost work per crash, this still means the possibility of far more than 1 million $ net worth damage dealt each day due to tmux instable design.

Sorry, just some math. (Note that "crash" includes "hang" or any other possibility, which stops all tmux session from becoming accessible. But hangs are the most frequent source of trouble with tmux and are not that fatal. As I once stumbled across a crude script somwhere - sorry I do no more remember - which allows to take over ttys, even from some hanging tmux. This creates some other problems afterwards and only works as long as the ttys are still open due to a hanging tmux server. If it really crashes, all ttys are closed.)

Improve this answer
1
  • 1
    The first part of this answer tries to answer the question, good. The most of the second part is a rant that does not belong here. The issue in question is not related to how frequently tmux crashes. And your math is unjust. Tmux is a free tool; if you think it brings you losses (or for whatever other reason), you are free to stop using it. People use tmux because it can boost productivity. It's enough for the boost to be worth $5.01 before the tool crashes and the net income is positive. Your rant is a libel that totally ignores that tmux is helpful before it crashes eventually (if ever). Commented Sep 8, 2023 at 20:25

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.