Idea #9181
closed
[Docker Cleaner] Crashes on startup when the Docker daemon has no events
Description
At least with Docker 1.7.1, if you ask for events in a series where there are none, it yields an empty string. Note this is not a bytes object, so when Docker cleaner tries to decode it, it crashes:
% sudo service docker restart
% py
Python 3.4.2 (default, Oct 8 2014, 10:45:20)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import docker, time
>>> t = int(time.time())
>>> dc = docker.Client(version='1.14')
>>> evs = dc.events(until=t - 1)
>>> next(evs)
''
>>> _.decode('utf-8')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'decode'
Docker cleaner should probably check for the empty string and treat it as a non-event.
Updated by Brett Smith over 8 years ago
- Target version set to Arvados Future Sprints
Updated by Radhika Chippada over 8 years ago
- Assigned To set to Lucas Di Pentima
Updated by Radhika Chippada over 8 years ago
- Target version changed from Arvados Future Sprints to 2016-06-22 sprint
Updated by Lucas Di Pentima over 8 years ago
- Status changed from New to In Progress
Reported behaviour couldn't be reproduced using Docker 1.6.2 and 1.8.2; Python version 3.4.2 & python3-docker package versions 1.7.2-1bpo8 (from June 2nd) and earlier version 1.7.2-1 (from March 30th) on Debian Jessie:
$ python Python 3.4.2 (default, Oct 8 2014, 10:45:20) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import docker, time >>> t = int(time.time()) >>> dc = docker.Client(version='1.14') >>> evs = dc.events(until=t-1) >>> next(evs) Traceback (most recent call last): File "<stdin>", line 1, in <module> StopIteration >>>
Updated by Brett Smith over 8 years ago
- Status changed from In Progress to Resolved
I see the same now with Docker 1.6.2, Python 3.4.2, docker-py 1.7.1 and 1.7.2 (installed from pip).
This is the main method that streams events. When I filed this, I looked at it and convinced myself that it was going into the else: branch, which can yield something very different from the loop in the main branch. But, definitely that conditional is very sensitive to the underlying stack: both what the Docker daemon returns, and how the requests library represents it. Given we can't reproduce this anymore, I think we're good to close this for now, figuring it's been addressed at some lower level of the stack. Thanks for digging into it so thoroughly.