[Bug 1090071] New: `docker start` doesn't fail on started container
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1090071
Bug ID: 1090071
Summary: `docker start` doesn't fail on started container
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
On older (0.9) docker, the `docker start $running_container` failed. The new
0.10.2 version just prints the container name and proceeds.
Version-Release number of selected component (if applicable):
docker-io-0.10.0-2.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. docker run -i -t -name test fedora bash
2. docker start test
Actual results:
[root@t530 ~]# docker start test
test
[root@t530 ~]# echo &?
0
Expected results:
[root@t530 ~]# docker start test
Error: Cannot start container test: The container
429d709bc86c037b09e9f74dfab40aa33dc19bcf3109daf3f5b2fbbd3c6df297 is already
running.
2014/04/22 15:29:28 Error: failed to start one or more containers
[root@t530 ~]# echo &?
1
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1096269] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1096269
Bug ID: 1096269
Summary: lost signals when sending lots of signals using
--sig-proxy to docker
Product: Red Hat Enterprise Linux 7
Version: 7.1
Component: docker
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: virt-bugs(a)redhat.com
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Depends On: 1087700
+++ This bug was initially created as a clone of Bug #1087700 +++
Description of problem:
When I send lots of signals to the running docker with --sig-proxy (actual kill
signals, not `docker kill`), most of them got lost.
Version-Release number of selected component (if applicable):
docker-0.10.0-8.el7.x86_64
docker-io-0.9.1-1.fc21.x86_64
How reproducible:
always
Steps to Reproduce:
1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly
localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap
"echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done'
2. ps ax |grep docker
3. for AAA in `seq 1 32`; do [ $AAA -ne 9 ] && [ $AAA -ne 20 ] && [ $AAA -ne 19
] && kill -s $AAA $PID; done
Actual results:
Output of the docker is:
Received 1, ignoring...
Received 2, ignoring...
Expected results:
Messages for all of the `Received $NUM, ignoring...` printed (order doesn't
matter)
Additional info:
Skipping 9, 19, 20 as they are a bit too special..
--- Additional comment from Lukas Doktor on 2014-05-05 04:10:09 EDT ---
The same results with upstream docker dc9c28f/0.10.0:
Output:
Received 1, ignoring...
[debug] stdcopy.go:111 framesize: 24
Received 2, ignoring...
Daemon output:
2014/05/05 10:08:45 POST
/v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=HUP
[/home/medic/Work/Projekty/Docker/root|fa3816b6] +job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP)
[/home/medic/Work/Projekty/Docker/root|fa3816b6] -job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, HUP) =
OK (0)
2014/05/05 10:08:45 POST
/v1.10/containers/b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5/kill?signal=INT
[/home/medic/Work/Projekty/Docker/root|fa3816b6] +job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT)
[/home/medic/Work/Projekty/Docker/root|fa3816b6] -job
kill(b01a849cb45ebe94c3a61fa021a5464186345d5b159faee4ea9d5da39fb36de5, INT) =
OK (0)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1087700
[Bug 1087700] lost signals when sending lots of signals using --sig-proxy
to docker
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1087697] New: man page inaccuracy about --sig-proxy and --tty
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1087697
Bug ID: 1087697
Summary: man page inaccuracy about --sig-proxy and --tty
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
Hi guys,
the man page states:
--sig-proxy=true: Proxify all received signal to the process (even
in non-tty mode)
But the real behavior is, that sig-proxy doesn't work when --tty=true. It
should be mentioned in there, taht --sig-proxy is incompatible with --tty.
Version-Release number of selected component (if applicable):
docker-io-0.9.1-1.fc21.x86_64
How reproducible:
always
Steps to Reproduce:
1. man docker
Actual results:
man page says it works even in non-tty
Expected results:
man page warns that --tty can't be used with --sig-proxy
How to verify:
1. docker run --tty=true -i --rm fedora bash -c 'for NUM in `seq 1 64`; do trap
"echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done'
2. ps -ax | grep docker
3. kill -SIGUSR1 $PID
4. (with --tty=true no signals are received, when you try the same with
--tty=false, signals are proxified and messages are displayed)
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1075232] New: 0.9.0 Adds virtual interface, NetworkManager attempts to assign dhcp address to it
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1075232
Bug ID: 1075232
Summary: 0.9.0 Adds virtual interface, NetworkManager attempts
to assign dhcp address to it
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: admiller(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Created attachment 873221
--> https://bugzilla.redhat.com/attachment.cgi?id=873221&action=edit
snippet from /var/log/messages for my laptop around the virtual interface
events
Description of problem:
When you install docker-io-0.9.0 on Fedora 20, it creates a new virtual
interface
13: vethf3e3: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master docker0
state UP group default qlen 1000
link/ether 1a:9c:40:61:1e:8b brd ff:ff:ff:ff:ff:ff
inet6 fe80::189c:40ff:fe61:1e8b/64 scope link
valid_lft forever preferred_lft forever
Something (I'm thinking dbus or udev) causes NetworkManager to launch dhclient
for the new interface, and if you're running with a Desktop Environment this
causes a visual change to the NM applet which can be confusing. It doesn't ever
do anything, NM eventually times out and gives up and this doesn't appear to
impact docker's functionality at all (or at least not yet in my tests have I
found an issue, networking works fine).
Version-Release number of selected component (if applicable):
docker-io-0.9.0-2.fc20.x86_64
How reproducible:
Always
Steps to Reproduce:
1. yum install docker-io #on a machine with a GUI/DE up and running with
NetworkManager
Actual results:
NetworkManager attempts to get a dhcp lease on the new virtual interface.
Expected results:
NetworkManager probably shouldn't attempt to get a dhcp lease on the new
virtual interface, this seems odd.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1033606] New: Failed to connect to network from Docker container
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1033606
Bug ID: 1033606
Summary: Failed to connect to network from Docker container
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: mfojtik(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: golang(a)lists.fedoraproject.org, lsm5(a)redhat.com,
mattdm(a)redhat.com, mgoldman(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
Connecting to external network from Docker container fail due to firewalld. I
guess you must have masquerade enabled, however this is not mentioned anywhere.
I think docker-io should set the firewalld rules automatically, or tell users
that they need to enable masquarade in firewalld.
Version-Release number of selected component (if applicable):
Name : docker-io
Arch : x86_64
Version : 0.7
Release : 0.17.rc6.fc20
Steps to Reproduce:
1. $ yum install docker-io
2. $ systemctl enable docker.service
3. $ systemctl start docker.service
4. $ docker pull mattdm/fedora
5. $ docker run -i -t mattdm/fedora:latest /bin/bash
6. $ ping google.com
ping: unknown host google.com
When I stop firewalld on host (systemctl stop firewalld) and then restart the
docker (systemctl restart docker), the ping works like a charm.
Actual results:
Unable to connect outside the Docker container with firewalld enabled.
Expected results:
Docker should configure firewalld automatically (during install?), or inform
users to do so manually.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 10 months
[Bug 1096286] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1096286
Bug ID: 1096286
Summary: "docker top all" doesn't show processes when
--tty=false
Product: Red Hat Enterprise Linux 7
Version: 7.1
Component: docker
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: virt-bugs(a)redhat.com
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Depends On: 1088259
+++ This bug was initially created as a clone of Bug #1088259 +++
After using the same magic required for the upstream docker 0.10 this behaves
the same on RHEL docker-0.10.0-8.el7.x86_64
Description of problem:
Hi guys, when I run docker with --tty=false, the `docker top $NAME all` doesn't
show any processes (just headers). When using only `docker top $NAME` it shows
them...
Also the `ps` command inside container works, but `ps all` does not.
Version-Release number of selected component (if applicable):
docker-0.10.0-8.el7.x86_64
docker-io-0.9.0-3.fc20.x86_64
How reproducible:
always
Steps to Reproduce:
1. docker run -i --tty=false fedora bash
2. docker logs $NAME
Actual results:
F UID PID PPID
PRI NI VSZ RSS
WCHAN STAT TTY TIME
COMMAND
Expected results:
F UID PID PPID
PRI NI VSZ RSS
WCHAN STAT TTY TIME
COMMAND
1 0 24006 23954
20 0 11732 540
- R pts/14 0:00
bash
--- Additional comment from Lukas Doktor on 2014-05-05 03:41:35 EDT ---
Can't reproduce with the upstream Docker version 0.10.0, build dc9c28f/0.10.0
top doesn't work at all (due of
https://bugzilla.redhat.com/show_bug.cgi?id=1088125 )
--- Additional comment from Lukas Doktor on 2014-05-05 03:46:07 EDT ---
OK I moved it to the old cgroup location and the results are the same. So
booth, fedora docker-io-0.9.0-3.fc20.x86_64 and upstream dc9c28f/0.10.0 are
unable to list processes using `all` argument in non-tty mode.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1088259
[Bug 1088259] "docker top all" doesn't show processes when --tty=false
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 11 months
[Bug 1088259] New: "docker top all" doesn't show processes when --tty=false
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1088259
Bug ID: 1088259
Summary: "docker top all" doesn't show processes when
--tty=false
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
Hi guys, when I run docker with --tty=false, the `docker top $NAME all` doesn't
show any processes (just headers). When using only `docker top $NAME` it shows
them...
Also the `ps` command inside container works, but `ps all` does not.
Version-Release number of selected component (if applicable):
docker-io-0.9.0-3.fc20.x86_64
How reproducible:
always
Steps to Reproduce:
1. docker run -i --tty=false fedora bash
2. docker logs $NAME
Actual results:
F UID PID PPID
PRI NI VSZ RSS
WCHAN STAT TTY TIME
COMMAND
Expected results:
F UID PID PPID
PRI NI VSZ RSS
WCHAN STAT TTY TIME
COMMAND
1 0 24006 23954
20 0 11732 540
- R pts/14 0:00
bash
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 11 months
[Bug 1102751] New: Got "Error running removeDevice" after kill -9 docker
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1102751
Bug ID: 1102751
Summary: Got "Error running removeDevice" after kill -9 docker
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: mfojtik(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
While I was playing with Docker today, I found interesting behavior:
When you 'kill -9' the 'docker -d' process, then this happens:
1. The 'docker -d' process gets killed ;-)
2. All containers gets killed
3. The 'docker -d' restarts, because of Restart=on-failure
Now, while all this is expected and OK, I get this when I tried to 'restart'
the container that was killed in 2):
May 29 13:24:56 ip-10-146-193-102 systemd[1]: Starting Container origin-db-1...
May 29 13:24:56 ip-10-146-193-102 sh[19731]: Reusing
b80104263de02f39bbc6d742c977ddadecb0660f5c50386eaf1cf645f3515b9c
May 29 13:25:07 ip-10-146-193-102 docker[19739]: Error: Cannot destroy
container origin-db-1: Driver devicemapper failed to remove root filesystem
e536cf328e0083e2414c750434deb1127517d00399fddac84903825d6f003787: Error running
removeDevice
May 29 13:25:07 ip-10-146-193-102 docker[19739]: 2014/05/29 13:25:07 Error:
failed to remove one or more containers
May 29 13:25:07 ip-10-146-193-102 gear[21193]: user: unknown user
ctr-origin-db-1
May 29 13:25:09 ip-10-146-193-102 docker[21192]: 2014/05/29 13:25:09 Error:
Cannot start container
bd1a88a35e84ef6d71fa3e1df0b4e2998318dfed6d60fd3ae381567fff2ac2a3: Cannot find
child for /origin-db-1
May 29 13:25:09 ip-10-146-193-102 systemd[1]: ctr-origin-db-1.service: main
process exited, code=exited, status=1/FAILURE
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Start up some containers
2. kill -9 (the 'docker -d' process pid)
3. Try to start the dead container again
4. Get the error above.
Actual results:
Expected results:
Containers should be successfully started back.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 11 months
[Bug 1087700] New: lost signals when sending lots of signals using --sig-proxy to docker
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1087700
Bug ID: 1087700
Summary: lost signals when sending lots of signals using
--sig-proxy to docker
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: ldoktor(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, skottler(a)redhat.com,
vbatts(a)redhat.com
Description of problem:
When I send lots of signals to the running docker with --sig-proxy (actual kill
signals, not `docker kill`), most of them got lost.
Version-Release number of selected component (if applicable):
docker-io-0.9.1-1.fc21.x86_64
How reproducible:
always
Steps to Reproduce:
1. /usr/bin/docker -D run --tty=false --rm -i --name test_eoly
localhost:5000/ldoktor/fedora:latest bash -c 'for NUM in `seq 1 64`; do trap
"echo Received $NUM, ignoring..." $NUM; done; while :; do sleep 1; done'
2. ps ax |grep docker
3. for AAA in `seq 1 32`; do [ $AAA -ne 9 ] && [ $AAA -ne 20 ] && [ $AAA -ne 19
] && kill -s $AAA $PID; done
Actual results:
Output of the docker is:
Received 1, ignoring...
Received 2, ignoring...
Expected results:
Messages for all of the `Received $NUM, ignoring...` printed (order doesn't
matter)
Additional info:
Skipping 9, 19, 20 as they are a bit too special..
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 11 months
[Bug 1093000] New: Unable to save an image to a tar archive
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1093000
Bug ID: 1093000
Summary: Unable to save an image to a tar archive
Product: Fedora
Version: 20
Component: docker-io
Assignee: lsm5(a)redhat.com
Reporter: lslebodn(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: admiller(a)redhat.com, golang(a)lists.fedoraproject.org,
lsm5(a)redhat.com, mattdm(a)redhat.com,
mgoldman(a)redhat.com, s(a)shk.io, vbatts(a)redhat.com
Description of problem:
I tried to dump content of docker image to a tarball with command "docker save"
It failed with error message "no space left on device"
Version-Release number of selected component (if applicable):
I was able to reproduce problem with docker-io from stable repository and with
docker-io from updates-testing
[root@vm-169 docker]# rpm -q docker-io
docker-io-0.9.1-1.fc20.x86_64
or
docker-io-0.10.0-2.fc20.x86_64
How reproducible:
Allways
Steps to Reproduce:
1. Create big docker image (e.g. 1.8 GiB)
[root@vm-169 docker-freeipa]# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
big_image latest b366efe500de 57 minutes ago 1.778 GB
fedora 20 b7de3133ff98 5 days ago 372.7 MB
2. save docker image to tarball
[root@vm-169 docker]# docker save big_image > big_image.tar
Actual results:
[root@vm-169 docker]# docker save big_image > big_image.tar
2014/04/30 12:39:38 Error: write
/docker-export-085323451/934d868afd0a79629df2cad704cbc1ed9344654625569263a630933d2785de57/layer.tar:
no space left on device
[root@vm-169 docker]# file big_image.tar
big_image.tar: empty
[root@vm-169 docker]# ls -l big_image.tar
-rw-r--r--. 1 root root 0 Apr 30 13:41 big_image.tar
Expected results:
File big_image.tar should not be empty and should contain data from docker
image with name big_image
Additional info:
Directory /tmp should be used for creating small temporary files, because it is
mounted on tmpfs. I think it would be better to use /var/tmp in this case.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 11 months