Docker-py: exec_run timeout while command still in progress

Created on 25 Jul 2018  路  2Comments  路  Source: docker/docker-py

Hello,

I recently bump into something that look like a bug.

Explanation

I have a python script that exec a command in a container. That command can take some times ( ~10 minutes)

client.containers.get("container_name").exec_run(["/bin/bash", "-c", "command"])

Even if the command is still executing on the remote container, I receive the following error

Traceback (most recent call last):
  File "backup.py", line 268, in <module>
    backup.method(list[0])
  File "backup.py", line 67, in backupGitLab
    result = client.containers.get(container_name).exec_run(["/bin/bash", "-c", "command"])
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/models/containers.py", line 185, in exec_run
    resp['Id'], detach=detach, tty=tty, stream=stream, socket=socket
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/utils/decorators.py", line 19, in wrapped
    return f(self, resource_id, *args, **kwargs)
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/api/exec_api.py", line 165, in exec_start
    return self._read_from_socket(res, stream, tty)
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/api/client.py", line 377, in _read_from_socket
    return six.binary_type().join(gen)
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/utils/socket.py", line 75, in frames_iter
    n = next_frame_size(socket)
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/utils/socket.py", line 62, in next_frame_size
    data = read_exactly(socket, 8)
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/utils/socket.py", line 47, in read_exactly
    next_data = read(socket, n - len(data))
  File "/home/gaetan/.local/lib/python2.7/site-packages/docker/utils/socket.py", line 31, in read
    return socket.recv(n)
socket.timeout: timed out

Even if the command is still running on the container, I receive a timeout error

Reproduction

I was able to reproduce this using the following code

client = docker.from_env(timeout=10)
result = client.containers.get(container_name).exec_run(["/bin/bash", "-c", "sleep 60"])

Expected behavior

The script should excute the sleep 60 command, and then end the script

Current behavior

I receive the same timeout error as the one above. Even if the command is still running ( and not in an error mode).
Timeout should occurs only when the command is not responding

Workaround

Set the timeout config to 600 secondes, in order to not have a timeout error

client = docker.from_env(timeout=600)

Questions

Is there any way to wait for a exec_run to finish ?
And is this a bug, because timeout should be receive only if a command is in error ?

Most helpful comment

This is not a bug, to be honest. There were a ton of bugs posted about this specifically that it might be time to revisit the design decision.

https://docker-py.readthedocs.io/en/stable/client.html?highlight=timeout#module-docker.client

The default timeout on the http connection is set to 60 seconds -- if the operation have not finished in those 60 seconds, you get the timeout error. So the workaround is actually a solution -- set it to some ridiculous number (e.g. 999999) and you won't be bothered.

All 2 comments

same here. Expecting to receive output generator and the logs in realtime. getting socket.timeout: timed out instead.
code:

exict_code, output=container.exec_run(cmd, stream=True)
for line in output:
    print(line, end='')

This is not a bug, to be honest. There were a ton of bugs posted about this specifically that it might be time to revisit the design decision.

https://docker-py.readthedocs.io/en/stable/client.html?highlight=timeout#module-docker.client

The default timeout on the http connection is set to 60 seconds -- if the operation have not finished in those 60 seconds, you get the timeout error. So the workaround is actually a solution -- set it to some ridiculous number (e.g. 999999) and you won't be bothered.

Was this page helpful?
0 / 5 - 0 ratings