Giter VIP home page Giter VIP logo

docker-gc's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docker-gc's Issues

Publish packages to bintray?

Thanks for making this useful tool.

However, the current installation process requires users to manually build system packages, and it would be great if these packaged can be pre-built and published to public service like Bintray.

AFAIK, there's an official Spotify team page on Bintray: https://bintray.com/spotify

get.docker.io redirect results in empty /bin/docker file

get.docker.io returns a 301 moved permanently status code to get.docker.com. cURL interprets this as success, a blank file is created in /bin/docker, and everything appears to have succeeded until you actually attempt to run the container and nothing happens.

It seems as though even the image on dockerhub has this issue.

The fix is simple, do one or both of:

  • Use the -L argument to tell cURL to follow redirects
  • Specify the get.docker.com url

Broken containers break docker-gc

Description

For some reason I'm not quite sure of yet, we sometimes end up with entries in /var/lib/docker/containers/ that docker does not recognize. This causes errors like Error: No such image or container: 3801e6aeaf57c...., which then causes docker-gc to error out before removing any containers. This builds up, and then we (since we apparently cron didn't send mail to the right place) have full disk.

How to reproduce

Not sure, sadly.

What do you expect

Ignore the missing container and remove the rest. Display summary afterwards with errors encountered.

What happened instead

No containers removed

Software:

  • bash version: 4.2.46(1)
  • docker version: 1.10.2 and 1.9.0

Incorrect process detection ("Process is already running")

Description

The new process detection (in 420558e) seems to be problematic when run with sudo. This is probably because sudo creates another copy of the process entry with root permissions, and then runs that. So there will be two copies in the process list.

If I switch to root, the command works just fine.

How to reproduce

  1. Run sudo docker-gc

What do you expect

Command completes successfully

What happened instead

docker-gc detects the original sudo request as a separate process, and refuses to run

Software:

  • bash version: GNU bash, version 4.3.42(1)-release
  • fgrep version: grep (GNU grep) 2.25
  • sudo version: Sudo version 1.8.16

Full backtrace

$ sudo docker-gc
[Mon Jun 27 11:47:26 EDT 2016] : docker-gc : Process is already running with PID 6817

Kills 'Created' state containers before they can run

Description

Because the container state "FinishedAt": "0001-01-01T00:00:00Z" is used for containers that have not exited yet, containers in the Created state are reaped despite the grace period setting. This is an issue for automation systems such as ECS that use the remote api to create and then start a container if docker-gc runs before the container starts.

How to reproduce

  1. Create a container using docker create
  2. Run docker-gc

What do you expect

Not to delete containers in the Created state before they have a chance to run.

Not compatible with OSX

Great work! Just one wee gotcha I hit that might be easy to fix...

grep on my mac throws an error if you try to use an empty input file. Critically, because this is used by docker-gc here and here, it means no containers or images are ever removed.

I think one potential work around would be to ensure that $EXCLUDE_IDS_FILE and $EXCLUDE_CONTAINERS_IDS_FILE have at least one line in them (perhaps something that will never match like '_FOO_'.

eg.

$ grep --version
grep (BSD grep) 2.5.1-FreeBSD

$ cat containers.reap.tmp
6bf92fe32e92765d85b381325e702349c8bd1edb44df1537addbc593b97c1942

$ cat exclude_container_ids

$ cat containers.reap.tmp | grep -v -f exclude_container_ids
Exit 1

$ echo '_FOO_' > exclude_container_ids

$ cat containers.reap.tmp | grep -v -f exclude_container_ids
6bf92fe32e92765d85b381325e702349c8bd1edb44df1537addbc593b97c1942

Docker-gc hangs

I just ran docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc as specified in the readme. It reported removing a bunch of containers, and now it seems to be hanging indefinitely.

> docker --version
Docker version 1.8.1, build 786b29d4

Tried it again - on the second run, it produces the same output (it reported removing the same containers, so it seems like it didn't actually do anything) and hangs in the same place.

GC cleans up exited containers before set grace period

Hi Guys,

I'm using the GC and I've set the GRACE_PERIOD_SECONDS=432000 (432000seconds is 5days) although for some reason it is removing exited containers that are over 5-6hours old.

Any ideas on why this might be happening?

Thanks,
Tommy

output/log which containers and images have been deleted

It would be nice if the script could output in some capacity what it had removed, to be able to trace back issues where an image/container was unexpectedly removed from a host.

The current version of the script keeps some output of what it has done in the "state directory" but this is overwritten each time the script is re-run.

For instance, I would like to be able to check /var/log/cron.log to see that docker-gc deleted image 123456 three hours ago, even if I have run the script 10 times more since then.

pidof: unrecognized option: x

Hello, we are using the docker-gc as a docker image running on our cluster. It is run as a systemd service with following ExecStart: docker run --name %p --rm -v /var/run/docker.sock:/var/run/docker.sock spotify/docker-gc || docker rmi spotify/docker-gc.

Issue we are seeing is:

Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: pidof: unrecognized option: x
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary.
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: Usage: pidof [OPTIONS] [NAME]...
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: List PIDs of all processes with names that match NAMEs
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: -s        Show only one PID
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: -o PID        Omit given pid
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: Use %PPID to omit pid of pidof's parent

And it seems like the process doesn't get run.

Thanks

[Edit] I suspect this is to do with difference of running natively vs running in a container that is using alpine:

~/docker run -ti alpine pidof -x
pidof: unrecognized option: x
BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary.

Usage: pidof [OPTIONS] [NAME]...

List PIDs of all processes with names that match NAMEs

    -s  Show only one PID
    -o PID  Omit given pid
        Use %PPID to omit pid of pidof's parent

[Edit#2] Can theonlydoo@7fc4110 use -s instead of -x as that option is available in BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary. used by Alpine?

busybox grep doesn't work with examples

The dockerfile uses alpine which is based on busybox.

The examples for excluding containers show a line like this

redis:[^ ]\+

However, the version of grep on busybox does not process the +.

The fix for this is to pass -E to grep. However, I haven't sent a PR because I'm not sure of the ramifications of this change. It might break for people who aren't running busybox.

bash-4.3# docker images
REPOSITORY                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
alpine                      latest              2314ad3eeb90        2 weeks ago         4.79 MB
bash-4.3# docker images         | tail -n+2         | sed 's/^\([^ ]*\) *\([^ ]*\) *\([^ ]*\).*/ \1:\2 \3 /' | grep "alpine:[^ ]\+"
bash-4.3# docker images         | tail -n+2         | sed 's/^\([^ ]*\) *\([^ ]*\) *\([^ ]*\).*/ \1:\2 \3 /' | grep -E "alpine:[^ ]+"
 alpine:latest 2314ad3eeb90

Add option to specify a sleep between each image removed

When deleting images, Docker appears to consume all the CPU, causing the entire machine to be unresponsive. One workaround would be to add a sleep option to "yield" after each image removed.
One the cli, I would run something like this
docker images -q --filter dangling=true | xargs -I % sh -c '{ docker rmi %; sleep 3; }'

Unexpected behavior of docker-gc

1 Run as a binary
Initialization: no /etc/docker-gc-exclude && /etc/docker-gc-exclude-containers files ( empty EXCLUDE_FROM_GC && EXCLUDE_CONTAINERS_FROM_GC ENV)
Run: After the execution, i would get a /var/lib/docker-gc/exclude_container_ids file containing all of the existing containers, while /var/lib/docker-gc/exclude_ids is empty, which is not expected.

2 Run as a docker container
Simple docker run --rm -v /var/run/docker.sock:/var/run/docker.sock spotify/docker-gc is not gonna work.
How could it possibly function well without accessing EXCLUDE_FROM_GC ENV (sort of stuff)? 'Cause it's located in /etc/docker-gc-exclude-containers.
We need a volume at least.

Doesn't seem to work with the OS X beta

Description

Hi!
I am running the OS X beta, and the gc doesn't seem to work here. Might be the run-statement is different on OS X, but here goes.

How to reproduce

Running the beta:

$ docker run mysql
$ docker ps -a 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                      PORTS               NAMES
c6520857da8c        mysql               "docker-entrypoint.sh"   13 minutes ago      Exited (1) 13 minutes ago                       jolly_payne

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
spotify/docker-gc   latest              a7bf2dad99ba        8 minutes ago       22.41 MB
mysql               latest              63a92d0c131d        3 days ago          374.1 MB
gliderlabs/alpine   3.2                 7a0dbfde8b8c        13 days ago         5.258 MB

$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc
Container running d92a5bb3b85944333e484b67a14e7c10da248dd6cd31c54b270b9810255d7344 /goofy_pare
Container not running c6520857da8c962074fd55b5590743442ecd07c7c6eae436986fad438042945a /jolly_payne
Removing image sha256:7a0dbfde8b8c592e6507117bd29b84a4ebc3f7c8e7dfa76b1d955c5606f51c59 [gliderlabs/alpine:3.2]

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                      PORTS               NAMES
c6520857da8c        mysql               "docker-entrypoint.sh"   15 minutes ago      Exited (1) 15 minutes ago                       jolly_payne

 docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
spotify/docker-gc   latest              a7bf2dad99ba        9 minutes ago       22.41 MB
mysql               latest              63a92d0c131d        3 days ago          374.1 MB
gliderlabs/alpine   3.2                 7a0dbfde8b8c        13 days ago         5.258 MB

What do you expect

The gc should remove both images and containers..

What happened instead

Doesn't happen

Software:

  • bash version: GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin14.5.0)

Support execution from OS X hosts via boot2docker.

Unfortunately docker-gc does not seem to work when used in combination with boot2docker even though the script exits with a 0 status code.

$ docker ps -a
CONTAINER ID        IMAGE                      COMMAND                CREATED              STATUS                      PORTS               NAMES
e2ef0285ccb5        redis:latest               "/entrypoint.sh redi   7 hours ago          Exited (0) 7 hours ago                          dock-redis
631656e621e7        mysql:latest               "\"/entrypoint.sh sh   10 days ago          Exited (1) 10 days ago                          ecstatic_mccarthy
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock spotify/docker-gc
$ docker ps -a
CONTAINER ID        IMAGE                      COMMAND                CREATED              STATUS                          PORTS               NAMES
e2ef0285ccb5        redis:latest               "/entrypoint.sh redi   7 hours ago          Exited (0) 7 hours ago                              dock-redis
631656e621e7        mysql:latest               "\"/entrypoint.sh sh   10 days ago          Exited (1) 10 days ago                              ecstatic_mccarthy

Date parsing breaks with docker 1.6.1 on Debian Jessie

With Docker version 1.6.1, build 97cd073:

$ sudo docker-gc
date: invalid date ‘"2015-07-25 09:26:5’
/usr/sbin/docker-gc: line 69: 1438142405 - : syntax error: operand expected (error token is "- ")

Bash trace:

$ sudo bash -x ./docker-gc 
+ set -o nounset
+ set -o errexit
+ GRACE_PERIOD_SECONDS=3600
+ STATE_DIR=/var/lib/docker-gc
+ DOCKER=docker
+ EXCLUDE_FROM_GC=/etc/docker-gc-exclude
+ '[' '!' -f /etc/docker-gc-exclude ']'
+ EXCLUDE_FROM_GC=/dev/null
+ EXCLUDE_IDS_FILE=exclude_ids
+ '[' '!' -d /var/lib/docker-gc ']'
+ cd /var/lib/docker-gc
+ docker version
+ docker ps -a -q --no-trunc
+ sort
+ uniq
+ docker ps -q --no-trunc
+ sort
+ uniq
+ compute_exclude_ids
+ PROCESSED_EXCLUDES=processed_excludes.tmp
+ sed 's/^\(.*\)$/ \1 /' /dev/null
+ sed '/^ *$/d'
+ docker images
+ tail -n+2
+ sed 's/^\([^ ]*\) *\([^ ]*\) *\([^ ]*\).*/ \1:\2 \3 /'
+ grep -f processed_excludes.tmp
+ cut '-d ' -f3
+ sed 's/^/^/'
+ comm -23 containers.all containers.running
+ echo -n ''
+ cat containers.exited
+ read line
++ docker inspect -f '{{json .State.FinishedAt}}' 16e1b23066c2462a70fd9c027a4e85a7ed0828f306c694c5ffec36d7c7160021
+ EXITED='"2015-07-25T09:26:54.517387651Z"'
++ elapsed_time '"2015-07-25T09:26:54.517387651Z"'
+++ date -u +%s
++ utcnow=1438143000
++ without_ms='"2015-07-25T09:26:5'
++ replace_t='"2015-07-25 09:26:5'
+++ date_parse '"2015-07-25 09:26:5'
+++ date --utc
++++ date -u --date '"2015-07-25 09:26:5' +%s
date: invalid date ‘"2015-07-25 09:26:5’
+++ echo
++ epoch=
./docker-gc: line 69: 1438143000 - : syntax error: operand expected (error token is "- ")
+ ELAPSED=
 $ 

It looks like the inspect returns surrounding quotes which are confusing the without_ms logic:

$ t=$(docker inspect -f '{{json .State.FinishedAt}}' 16e1b23066c2462a70fd9c027a4e85a7ed0828f306c694c5ffec36d7c7160021)
$ echo $t
"2015-07-25T09:26:54.517387651Z"
$ echo ${t:0:19}
"2015-07-25T09:26:5

ValueError: time data '2015-06-17' does not match format '%Y-%m-%dT%H:%M:%S'

sudo docker-gc
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
    (data_string, format))
ValueError: time data '2015-06-17' does not match format '%Y-%m-%dT%H:%M:%S'

This is an error I get from freshly installed docker-gc on Ubuntu 15.04 amd64, Docker 1.7.0. My first guess was something locale related, but looking at the specificity of the expected format, I suppose it could be due to Docker (or some other piece of software along the way) changing some date format to a less accurate form. I have written a /etc/docker-gc-exclude file. I'll be happy to supply additional details if you need some.

Failed to run docker-gc due to a invalid syntax error

I'm trying to run docker-gc on my Raspberry Pi. This is the first time I've attempted to run it. I checked it out, built and installed it with only these issues

...
warning: the authors of lintian do not recommend running it with root privileges!
E: docker-gc: no-copyright-file
E: docker-gc: extended-description-is-empty
W: docker-gc: binary-without-manpage usr/sbin/docker-gc
Finished running lintian.

I added an excludes file to my default location that just has "latest" in it.
I run the command manually and the results are...

$ docker-gc
Container not running 026614557a1a053dab3225b85216d14169fc8f9bca8ff9011319db41086d5133 /distracted_visvesvaraya
...
Container not running ffc72f6f12f8202af21fe3204ace4c2867277b213bf13d4c5457c1d35442c035 /sharp_ritchie

And then this is the error thrown at the end...

date: invalid date ‘0001-01-01 00:00:00’
/usr/sbin/docker-gc: line 102: 1456619521 - : syntax error: operand expected (error token is "- ")

No images were removed after this error was thrown. Is this a bug or did I just overlook something?

df: ‘/var/lib/docker’: No such file or directory

Description

Finishing the clean up, I get this error

df: ‘/var/lib/docker’: No such file or directory

My Docker Root Dir is changed but seems process does not follow it, just go to default Docker Root Dir (/var/lib/docker/)

How to reproduce

Change Docker Root Dir
Launch the clean up

What do you expect

No error.

What happened instead

df: ‘/var/lib/docker’: No such file or directory
Finished Cleanup (bytes free )

Software:

  • bash version: GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu)
  • OS version: Debian 8.5
  • docker version: Docker version 1.12.1, build 23cf638

Full backtrace


The following command will
- Delete all docker images for old containers
- Delete all stopped and orphan containers

Are you sure (Y/n): y
df: ‘/var/lib/docker’: No such file or directory
Starting Cleanup (bytes free )
Unable to find image 'samsaffron/docker-gc:latest' locally
latest: Pulling from samsaffron/docker-gc

0f4d770cd333: Pull complete 
a3ed95caeb02: Pull complete 
6a2ea02ca5be: Pull complete 
bc4c30afebbb: Pull complete 
Digest: sha256:1efd5febba28f881c815c37005b09c67fce0fa62d583b82790b0a0fe82cad999
Status: Downloaded newer image for samsaffron/docker-gc:latest
df: ‘/var/lib/docker’: No such file or directory
Finished Cleanup (bytes free )

Running docker-gc while a pull is running corrupts the image

If a docker pull is running while docker-gc executes it deletes intermediate layers of the currently pulled image, corrupting the download. If you try to create a container from the corrupt image, it shows an error that it cannot find an intermediate image.

On a machine of mine I'm running a similar code which removes untagged images with the command:
docker rmi $(docker images -q --filter "dangling=true")
This has the same issues and because of that I'm running it only nightly once when there's no other maintenance method is running.

I wonder if this could be improved somehow. It would be really helpful to run docker-gc more often on eg. a Jenkins build machine, where each commit can trigger a new build with a new image and we can run out of disk space quickly.

This can be really hard to fix because of the race conditions.

docker rmi will fail if image has multiple repo:tag references

Learn many from docker-gc. I didn't run docker-gc but read the code.

the docker-gc's way of remove a image is

docker rmi $(image_id)

if the image has multiple repo:tag reference to it, the command will fail.
my shell removes repo:tag instead of imageid mostly, avoid the bug.

Template parsing errors when running docker-gc

Description

When running docker-gc I get a list of template errors logged:

Template parsing error: template: :1:2: executing "" at <.Tags>: Tags is not a field of struct type types.ImageInspect
Removing image 010a096fc84648e91a06c39a451f333b543d71dc01f3e8ac83bfdf7a39aaf18f 

How to reproduce

Use an old version of docker-gc with a newer version of docker.

What do you expect

The command to run without producing any errors.

What happened instead

I got multiple errors.

Software:

  • bash version: 4.3.11(1)
  • docker 1.9.1
  • docker-gc (e194bc0)

Error: No such image or container:xxxxx

Description

when I run "GRACE_PERIOD_SECONDS=1296000 docker-gc" command I get These

Container not running d9124c0ca7f9e4636dedd6455b52cd33e4dad387b8c4be56d35f33c86d9e5730 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.d2d27562-e31d-4a8d-a46f-5284a41b10bf
Container not running d9d256bf9df5b322064e69866f9d482aa073ea2b67eea7335c74a3f440db2e65 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.2f803c08-0d57-4752-b172-eb875ba15bdb
Container not running d9fa5d75765c140cf1d92c446e85e450e6599b23407ecd1f6782ab40a63b8415 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.774c05af-d679-4c4f-bbe2-24afb37211a8
Error: No such image or container: da7d5edc4a967929889cbfff956140191ff9e76f2bc6a633ecfd81b00c794f45
Container not running da7d5edc4a967929889cbfff956140191ff9e76f2bc6a633ecfd81b00c794f45 
Container not running dbc831d205bb7764140701b74126527147ee11722c686e2f0a68642b0696b75c /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.54e53a86-c1a3-403b-ac3e-5e3360253d0d
Container not running fef99a14b6a6194fede5c6536ce5ed70d4293566cb31a35845734acfff058904 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.9a999470-d855-4d72-a722-ab0cac88668b
Error: No such image or container: c28e76941974e662bb83b7cda955425b70196fd5c79b3215de99236682107279

then the gc work would not work.

If I manually remove the error containers and run again the command , it will work well .

How to reproduce

Just run "GRACE_PERIOD_SECONDS=1296000 docker-gc" command
The old containers we have more than 100.

Image tags are removed

Description

docker-gc removes all image tags that are used in my custom images. I'm running docker-gc daily on my CI server. The CI jobs build the Dockerfiles every time and because docker-gc removes the image tags they have to be refetched once a day.

How to reproduce

Step 1: Create a Dockerfile:

FROM node:5.9.1-slim
CMD ["node", "-v"]

Step 2: Build it, tag it, run it. (this is what my CI job does)

docker build -t foobar .
docker run foobar

Step 3: Confirm cached steps.

docker build -t foobar .
# Everything should be cached.

Step 4: Garbage collection.

# Use a small GRACE_PERIOD_SECONDS for this demo.
# In production I use the default value.
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc \
  -e "GRACE_PERIOD_SECONDS=1" spotify/docker-gc

Step 5: Build it again.

docker build -t foobar .

What do you expect

The FROM: node:5.9.1-slim step is cached.

What happened instead

Docker pulls the node:5.9.1-slim image again. From the README:

we take extra care to not remove any image tags (e.g., ubuntu:14.04, busybox, etc) that are in use by containers

Maybe I have the wrong expectations from it. Is there any way that I can stop it from deleting my image tags besides using the exclude env variable? I'd like to use it as last resort as it's not maintainable if new custom images show up that use other image tags.

Software:

Docker version 1.9.1, build a34a1d5

Run docker-gc as a container and seems not working

After the container exits, the garbage are still there. Did i miss anything?
FYI.

$ docker ps -a
CONTAINER ID        IMAGE                                       COMMAND                CREATED             STATUS                     PORTS                    NAMES
9efcbc88a5a7        spotify/docker-gc                           "/docker-gc"           3 hours ago         Exited (0) 3 hours ago                              pensive_babbage                                                                                                        
ed3e262a531b        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend1.1-glg6b_default_8f56aae4-1700-11e5-bbc4-005056b462d8_be7f57fd                         
56145037475a        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend1.1-glg6b_default_8f56aae4-1700-11e5-bbc4-005056b462d8_2fa8eda0                               
4072f04f94b7        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago         Exited (137) 7 weeks ago                            k8s_php-redis.406c1646_frontend1.11.11-ey77r_default_8f536ebe-1700-11e5-bbc4-005056b462d8_805defa3                     
702acf4ac038        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend1.11.11-ey77r_default_8f536ebe-1700-11e5-bbc4-005056b462d8_9837a786                           
104aacc3f82a        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago         Exited (137) 7 weeks ago                            k8s_php-redis.406c1646_frontend2-d7c10_default_8069cf68-1700-11e5-bbc4-005056b462d8_6a87bd07                           
ad69bf0c7bb4        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend2-d7c10_default_8069cf68-1700-11e5-bbc4-005056b462d8_b9b421f8                                 
c3d2e7ff2673        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago         Exited (137) 7 weeks ago                            k8s_php-redis.406c1646_frontend2-rxdc3_default_7d730dff-1700-11e5-bbc4-005056b462d8_5978a680                           
34f8428bbe87        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago         Exited (137) 7 weeks ago                            k8s_php-redis.406c1646_frontend2-g0b5x_default_7c4affa6-1700-11e5-bbc4-005056b462d8_8d471ab5                           
561c3a2d848b        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend2-rxdc3_default_7d730dff-1700-11e5-bbc4-005056b462d8_c0070f2f                                 
a040e2208567        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend2-phomo_default_7c3bc0ec-1700-11e5-bbc4-005056b462d8_66a07d2f                           
a0828ebd1424        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend2-g0b5x_default_7c4affa6-1700-11e5-bbc4-005056b462d8_4ed343d8                                 
34f88178f812        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend1.11.11-o64ha_default_7aa914bd-1700-11e5-bbc4-005056b462d8_ed59ff7b                     
675ff1bc9874        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend1.11.11-m90st_default_7aaa6160-1700-11e5-bbc4-005056b462d8_cc3df47b                     
960eb976f699        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend2-phomo_default_7c3bc0ec-1700-11e5-bbc4-005056b462d8_a499b54b                                 
0d69c7ba1746        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend1.11.11-o64ha_default_7aa914bd-1700-11e5-bbc4-005056b462d8_ee66382d                           
74242b609cd2        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend1.11.11-m90st_default_7aaa6160-1700-11e5-bbc4-005056b462d8_6ad1a950                           
d6db1e21bd0e        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend2-skzkr_default_60b56ee5-1700-11e5-bbc4-005056b462d8_3e709dc3                           
efab6cd76f1e        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend2-skzkr_default_60b56ee5-1700-11e5-bbc4-005056b462d8_421e0263                                 
de5c65a6d56a        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago         Exited (137) 7 weeks ago                            k8s_php-redis.406c1646_frontend2-05zzs_default_56aea9cb-1700-11e5-bbc4-005056b462d8_6c2aa19c                           
7a2eaffb65fc        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend2-05zzs_default_56aea9cb-1700-11e5-bbc4-005056b462d8_f0ae6639                                 
316eb5ef5112        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago         Exited (137) 7 weeks ago                            k8s_php-redis.406c1646_frontend1.11.11-o4loc_default_53b89715-1700-11e5-bbc4-005056b462d8_1b89f736                     
fe49dc0d98ad        gcr.io/google_containers/pause:0.8.0        "/pause"               7 weeks ago         Exited (0) 7 weeks ago                              k8s_POD.3f830436_frontend1.11.11-o4loc_default_53b89715-1700-11e5-bbc4-005056b462d8_96aabde1                           
b3145d2d2e12        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend1.1-wii8j_default_51253f1d-1700-11e5-bbc4-005056b462d8_6b595f97                         
87d82260121e        kubernetes/example-guestbook-php-redis:v2   "/bin/sh -c /run.sh"   7 weeks ago                                                             k8s_php-redis.406c1646_frontend1.11.11-89lm7_default_516961a1-1700-11e5-bbc4-005056b462d8_b597a08e                     
...

And NO ERROR has been reported.

ENV

ubuntu 14.04

$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

lintian fails the build on debian jessie

On debian jessie (8):

dpkg-buildpackage: binary-only upload (no source included)
Now running lintian...
E: docker-gc: no-copyright-file
E: docker-gc: extended-description-is-empty
W: docker-gc: binary-without-manpage usr/sbin/docker-gc
Finished running lintian.

Can be avoided by using --no-lintian, eg:

$ debuild --no-lintian -us -uc -b

Mixed use of `docker` and `$DOCKER`

Example of docker usage in the script:

cat containers.keep |
xargs -n 1 docker inspect -f '{{.Config.Image}}' 2>/dev/null |
sort | uniq |
xargs -n 1 docker inspect -f '{{.Id}}' 2>/dev/null |
sort | uniq > images.used

Is this by design? Or can I make a pull request to unify the method of calling docker?

Failing to parse date on Ubuntu 14.04.2 LTS

When I run docker-gc on Ubuntu 14.04.2 LTS, I get the following error message:

date: invalid date ‘"2015-07-29 16:16:2’
/usr/sbin/docker-gc: line 69: 1438186643 - : syntax error: operand expected (error token is "- ")

Am I doing something wrong? Thanks!

Doc should mention it needs to be run as root

When built as a debian package it creates /var/lib/docker-gc/ with perms drwxr-xr-x and owned by root.

The script then tries to write to this directory, which fails if docker-gc is run as a regular user, eg:

$ /usr/sbin/docker-gc 
/usr/sbin/docker-gc: line 111: containers.all: Permission denied

Prevent removal of Data Containers

Just noticed my hourly docker-gc cron was removing my data only containers 😱

Is the only way to prevent this to add them as an exception? Could docker-gc check for VolumesFrom?

Allow passing "EXCLUDE_CONTAINERS" and "EXCLUDE_IMAGES" as environmental vars

Background

Right now to set images and containers to exclude from the cleanup we need to:

  1. Write the lists to files
  2. Map the files into the docker-gc container

Far simpler to allow environmental variables which contain a comma separated list of the containers or images.

Having to put the excluded images and containers into files and then map the volume complicates things a lot in some cases, here's an example: Jenkins (which is dockerized but has control over the hosts docker server by mounting the docker socket as a volume) runs the docker-gc regularly. In order to specify the containers and images to exclude, Jenkins needs to first put the files on the host (which requires additional volumes mounted into Jenkins) and then map those same files into the docker gc container. If we could pass in the excluded images and containers as environmental variables when the docker gc container is run it would be much simpler.

The proposal

This proposal is for two new environmental variables called EXCLUDE_CONTAINERS and EXCLUDE_IMAGES. They would be used as follows (example):

$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -e EXCLUDE_CONTAINERS=container-one,container-two -e EXCLUDE_IMAGES=image-one,image-two spotify/docker-gc

Functionality

The functionality would be:
Excluded containers:

  • If the EXCLUDE_CONTAINERS environmental variable is set then it takes priority, if the /etc/docker-gc-exclude-containers file exists it is ignored.
  • If no EXCLUDE_CONTAINERS environmental variable is set then the behaviour is the same as right now; we check the /etc/docker-gc-exclude-containers file and get the excluded containers from there (or exclude no containers if the file doesn't exist).

Excluded images:

  • If the EXCLUDE_IMAGES environmental variable is set then it takes priority, if the /etc/docker-gc-exclude file exists it is ignored.
  • If no EXCLUDE_IMAGES environmental variable is set then the behaviour is the same as right now; we check the /etc/docker-gc-exclude file and get the excluded images from there (or exclude no images if the file doesn't exist).

Test sandbox

Description

I want to test the behaviour of this component before put it on my infrastructure, do you have a load testing script to increase the number of containers and memory consumption ?

What do you expect

I am requesting for an advice.

Feature: Dry Run

Please add an option to run the script just to show what would be removed instead of removing right away.

Support for removing Dead containers?

Thank you for docker-gc, it is working nicely for us.

What I did notice is that it doesn't currently remove Dead containers (or it tries and is unsuccessful).

It looks like docker-gc wants to keep them:

$ docker ps -a | grep Dead
45c3be6ad58e        myimage              "myproc"   4 days ago          Dead
66feab2765bd        myimage              "myproc"   4 days ago          Dead
2a45be87379e        myimage              "myproc"   4 days ago          Dead
b8d073da4fac        myimage              "myproc"   4 days ago          Dead
c0dba5cc5f20        myimage              "myproc"   4 days ago          Dead

$ grep 45c3b /var/lib/docker-gc/*
/var/lib/docker-gc/containers.all:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/containers.exited:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/containers.keep:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/containers.reap.tmp:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/exclude_container_ids:45c3be6ad58e

$ grep 66fea /var/lib/docker-gc/*
/var/lib/docker-gc/containers.all:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/containers.exited:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/containers.keep:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/containers.reap.tmp:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/exclude_container_ids:66feab2765bd

Although not necessarily common, it would be good to cover these or at least output them to a .dead file which can be monitored and addressed a person or another tool.

RHEL support would be much appreciated

Our production RHEL docker bloat is pretty hellacious. I would be able to hardly "contain" myself were I able to welcome docker-gc into my CentOS boxen to help clean up.

Thanks in advance for your consideration of this feature request.

Configure grace period

It would be great if one could configure the grace period $GRACE_PERIOD_SECONDS. I suppose a good way would be to have a /etc/default/docker-gc file that you can source in your script. Such a file would just contain one line export GRACE_PERIOD_SECONDS=3600.

This would help a lot! Thanks!
Michel

Removes containers that were never started?

I haven't yet tried it out (cuz the install required doing stuff on my machine that I don't yet want to do...), but it looks like containers that were created (e.g., via docker create busybox), but not started, will be garbage-collected because the "FinishedAt" timestamp is "0001-01-01T00:00:00Z", which is certainly more than an hour ago.

Am I misreading the code here?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.