Skip to content

Request: list_sessions to return an empty list if 'no server running on ...' #447

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
xlucn opened this issue Oct 11, 2022 · 2 comments · Fixed by #448
Closed

Request: list_sessions to return an empty list if 'no server running on ...' #447

xlucn opened this issue Oct 11, 2022 · 2 comments · Fixed by #448

Comments

@xlucn
Copy link

xlucn commented Oct 11, 2022

The problem is that I can't find a method to check if there is any sessions running, or tmux server running (for the current socket), without catching a LibTmuxException exception. It will be convenient to check that by telling whether the list is empty or not.

Same goes for sessions and attached_sessions attributes.

It is strange/unexpected to get an exception from common tasks like accessing an attribute or requiring a list of something.

Or, a more direct solution is to add a function to check the availability of the server.

@tony
Copy link
Member

tony commented Oct 11, 2022

@oliverlew This issue has come up before

cc: @rockandska

Any thoughts on a default error, or better behavior when no server connection exists?

I am +1 on having sessions and attached_sessions be empty, e.g. [] if no server exists, and then perhaps have an .alive or .connected property, or .is_connected()

Any other ideas?

We also want to make sure we don't break any APIs for existing users

@tony
Copy link
Member

tony commented Oct 11, 2022

It is strange/unexpected to get an exception from common tasks like accessing an attribute or requiring a list of something.

The thinking was that libtmux is a client, and would behave like tmux(1), or like any other client interface would

redis-cli  --bigkeys
Could not connect to Redis at 127.0.0.1:6379: Connection refused
~ ❯ python
Python 3.10.7 (main, Sep 18 2022, 17:05:16) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
ptpython is not available: falling back to standard prompt
>>> import redis
>>>
>>> r = redis.StrictRedis(host='localhost', port=6379, db=0)
... print(r.execute_command('INFO')['redis_version'])
python -c "import redis; print(redis.StrictRedis(host='localhost', port=6379, db=0).execute_command('INFO')['redis_version'])"
Traceback (most recent call last):
  File "python3.10/site-packages/redis/connection.py", line 611, in connect
    sock = self.retry.call_with_retry(
  File "python3.10/site-packages/redis/retry.py", line 46, in call_with_retry
    return do()
  File "python3.10/site-packages/redis/connection.py", line 612, in <lambda>
    lambda: self._connect(), lambda error: self.disconnect(error)
  File "/home/t/.local/lib/python3.10/site-packages/redis/connection.py", line 677, in _connect
    raise err
  File "python3.10/site-packages/redis/connection.py", line 665, in _connect
    sock.connect(socket_address)
ConnectionRefusedError: [Errno 111] Connection refused

Today I am more flexible on the idea of having sessions / attached_sessions return [].

Caveat: that may not necessarily be the same as a client existing or not:

Assuming exit-empty is off (by default, it's on):

tmux start-server

The server would stay on, but return no sessions.

     start-server
                   (alias: start)
             Start the tmux server, if not already running, without creating any sessions.

             Note that as by default the tmux server will exit with no sessions, this is only useful if a session is
             created in ~/.tmux.conf, exit-empty is turned off, or another command is run as part of the same command
             sequence.  For example:

                   $ tmux start \; show -g

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants