Closed MElhagaly closed 4 years ago
Can you maybe check if you have a /etc/docker/daemon.json file and what it contains? And also run ‘docker info | grep "Storage Driver"’ it seems like Docker wants to use the aufs storage driver but can’t find it.
@ntimo I unfortunately cannot find the deamon.json file. Executing ls
in /etc/docker
only shows: key.json
running docker info | grep "Storage Driver"
outputs
Storage Driver: aufs
WARNING: the aufs storage-driver is deprecated, and will be removed in a future release.
Same Probleme here, occured after updating mailcow via update.sh You can create / start the container by hand, they are up and running but running into error 128 after OS restart. Some kind of failing dependency?
Ubuntu 16.04.6 LTS
Docker version 19.03.3, build a872fc2
docker info | grep "Storage Driver"
Storage Driver: overlay2
WARNING: No swap limit support
ll /etc/docker/
insgesamt 12
drwx------ 2 root root 4096 Mär 18 2018 ./
drwxr-xr-x 96 root root 4096 Okt 10 17:46 ../
-rw------- 1 root root 244 Mär 2 2018 key.json
Anyone created a report at moby or Ubuntu?
My recommendation is to "down" the stack and upgrade to 18.04.
I don't think that we can fix it here.
If someone is fine with me checking their 16.04 setup, mail me. I will try to upgrade and fix the stack.
@andryyy so no problems with docker version 19.03.3 and ubuntu 18.04?
from my apt update logs I get the following
Log started: 2019-10-09 22:53:17
(Reading database ... 136039 files and directories currently installed.)
Preparing to unpack .../libpython3.5_3.5.2-2ubuntu0~16.04.9_amd64.deb ...
Unpacking libpython3.5:amd64 (3.5.2-2ubuntu0~16.04.9) over (3.5.2-2ubuntu0~16.04.8) ...
Preparing to unpack .../python3.5_3.5.2-2ubuntu0~16.04.9_amd64.deb ...
Unpacking python3.5 (3.5.2-2ubuntu0~16.04.9) over (3.5.2-2ubuntu0~16.04.8) ...
Preparing to unpack .../libpython3.5-stdlib_3.5.2-2ubuntu0~16.04.9_amd64.deb ...
Unpacking libpython3.5-stdlib:amd64 (3.5.2-2ubuntu0~16.04.9) over (3.5.2-2ubuntu0~16.04.8) ...
Preparing to unpack .../python3.5-minimal_3.5.2-2ubuntu0~16.04.9_amd64.deb ...
Unpacking python3.5-minimal (3.5.2-2ubuntu0~16.04.9) over (3.5.2-2ubuntu0~16.04.8) ...
Preparing to unpack .../libpython3.5-minimal_3.5.2-2ubuntu0~16.04.9_amd64.deb ...
Unpacking libpython3.5-minimal:amd64 (3.5.2-2ubuntu0~16.04.9) over (3.5.2-2ubuntu0~16.04.8) ...
Preparing to unpack .../libpython2.7_2.7.12-1ubuntu0~16.04.9_amd64.deb ...
Unpacking libpython2.7:amd64 (2.7.12-1ubuntu0~16.04.9) over (2.7.12-1ubuntu0~16.04.8) ...
Preparing to unpack .../python2.7_2.7.12-1ubuntu0~16.04.9_amd64.deb ...
Unpacking python2.7 (2.7.12-1ubuntu0~16.04.9) over (2.7.12-1ubuntu0~16.04.8) ...
Preparing to unpack .../libpython2.7-stdlib_2.7.12-1ubuntu0~16.04.9_amd64.deb ...
Unpacking libpython2.7-stdlib:amd64 (2.7.12-1ubuntu0~16.04.9) over (2.7.12-1ubuntu0~16.04.8) ...
Preparing to unpack .../python2.7-minimal_2.7.12-1ubuntu0~16.04.9_amd64.deb ...
Unpacking python2.7-minimal (2.7.12-1ubuntu0~16.04.9) over (2.7.12-1ubuntu0~16.04.8) ...
Preparing to unpack .../libpython2.7-minimal_2.7.12-1ubuntu0~16.04.9_amd64.deb ...
Unpacking libpython2.7-minimal:amd64 (2.7.12-1ubuntu0~16.04.9) over (2.7.12-1ubuntu0~16.04.8) ...
Preparing to unpack .../docker-ce-cli_5%3a19.03.3~3-0~ubuntu-xenial_amd64.deb ...
Unpacking docker-ce-cli (5:19.03.3~3-0~ubuntu-xenial) over (5:19.03.2~3-0~ubuntu-xenial) ...
Preparing to unpack .../docker-ce_5%3a19.03.3~3-0~ubuntu-xenial_amd64.deb ...
Unpacking docker-ce (5:19.03.3~3-0~ubuntu-xenial) over (5:19.03.2~3-0~ubuntu-xenial) ...
Preparing to unpack .../cloud-init_19.2-36-g059d049c-0ubuntu2~16.04.1_all.deb ...
Unpacking cloud-init (19.2-36-g059d049c-0ubuntu2~16.04.1) over (19.2-36-g059d049c-0ubuntu1~16.04.1) ...
Preparing to unpack .../grafana_6.4.2_amd64.deb ...
Unpacking grafana (6.4.2) over (6.4.1) ...
Processing triggers for libc-bin (2.23-0ubuntu11) ...
Processing triggers for mime-support (3.59ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu21.22) ...
Setting up libpython3.5-minimal:amd64 (3.5.2-2ubuntu0~16.04.9) ...
Setting up libpython3.5-stdlib:amd64 (3.5.2-2ubuntu0~16.04.9) ...
Setting up libpython3.5:amd64 (3.5.2-2ubuntu0~16.04.9) ...
Setting up python3.5-minimal (3.5.2-2ubuntu0~16.04.9) ...
Setting up python3.5 (3.5.2-2ubuntu0~16.04.9) ...
Setting up libpython2.7-minimal:amd64 (2.7.12-1ubuntu0~16.04.9) ...
Setting up libpython2.7-stdlib:amd64 (2.7.12-1ubuntu0~16.04.9) ...
Setting up libpython2.7:amd64 (2.7.12-1ubuntu0~16.04.9) ...
Setting up python2.7-minimal (2.7.12-1ubuntu0~16.04.9) ...
Setting up python2.7 (2.7.12-1ubuntu0~16.04.9) ...
Setting up docker-ce-cli (5:19.03.3~3-0~ubuntu-xenial) ...
Setting up docker-ce (5:19.03.3~3-0~ubuntu-xenial) ...
Setting up cloud-init (19.2-36-g059d049c-0ubuntu2~16.04.1) ...
Leaving 'diversion of /etc/init/ureadahead.conf to /etc/init/ureadahead.conf.disabled by cloud-init'
Setting up grafana (6.4.2) ...
Restarting grafana-server service... OK
Processing triggers for libc-bin (2.23-0ubuntu11) ...
Log ended: 2019-10-09 22:53:58
Log started: 2019-10-10 20:15:20
(Reading database ... 136039 files and directories currently installed.)
Preparing to unpack .../base-files_9.4ubuntu4.11_amd64.deb ...
Unpacking base-files (9.4ubuntu4.11) over (9.4ubuntu4.8) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up base-files (9.4ubuntu4.11) ...
(Reading database ... 136043 files and directories currently installed.)
Preparing to unpack .../containerd.io_1.2.10-2_amd64.deb ...
Unpacking containerd.io (1.2.10-2) over (1.2.6-3) ...
Setting up containerd.io (1.2.10-2) ...
Log ended: 2019-10-10 20:15:26
Seeing this I think that the problems started occurring after updating containerd.io from 1.2.6-3 to 1.2.10-2. I came to this conclusion because I was able to receive emails yesterday afternoon & evening.
I also found this issue at the docker for-linux repos: https://github.com/docker/for-linux/issues/813
Would downgrading the version of containerd.io help solving the issue?
ubuntu 18.04 containerd.io: containerd.io/bionic,now 1.2.6-3 amd64 docker: 19.03.3, build a872fc2f86
no issues
@andryyy A technical question while solving the issue. People have reached out to me asking about email I supposedly received. My question is: will I receive said emails when I am back up and running or are they lost in void?
will I receive said emails when I am back up and running or are they lost in void?
Email servers are expected to keep trying to deliver a message for at least three days before they give up and notify the sender. So you will eventually receive your missed messages since you fixed your server quickly enough.
I fixed the issue by downgrading containerd.io to 1.2.6-3 and so far I am back up and running.
so.... is containerd.io=1.2.6-3
a hard version dependency for now? Should everyone running mailcow on ubuntu 18.04 be pinning to that version?
at the moment, apt upgrade wants to install containerd.io=1.2.10-2
.
@pjv containerd.io=1.2.6-3
is the latest version of containerd.io that works for me. Upgrading to containerd.io=1.2.10-2
broke everything using docker on my system. I am not sure if anyone has containerd.io=1.2.10-2
working with mailcow.
My recommendation for the time being is remain using containerd.io=1.2.6-3
until newer version of containerd are tested approved by the community.
I am running containerd.io 1.2.10-2 on my ubuntu 18.04 mailcow box running smoothly
I too had to revert to version containerd.io=1.2.6-3
You guys need to create issues at moby or Ubuntu :(
Summary from the upstream issue: When the package containerd.io was updated, it did not correctly restart the containerd service in the postinstall steps.
Just restart containerd service: service containerd restart
Thank you! :)
Am 18.10.2019 um 11:53 schrieb Philipp Gassmann notifications@github.com:
Summary from the other issue: When the package containerd.io was updated, it did not correctly restart the containerd service in the postinstall steps.
Just restart containerd service: service containerd restart
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Anyone created a report at moby or Ubuntu?
My recommendation is to "down" the stack and upgrade to 18.04.
I don't think that we can fix it here.
If someone is fine with me checking their 16.04 setup, mail me. I will try to upgrade and fix the stack.
Andryyy, I am 100% fine with you trying to do that on mine. I am on 16.04. Since I did an update today, Dovecot is having many errors. I emailed them to the info email address. Im begging for help. I would purchase the support but I am a poor college student who is still learning computer science. Please help,
@choffman5718 I think you should consider looking at the latest post on the mailcow website.
I already helped him and we upgraded the kernel. :)
You both are the greatest, thank you so so much.
Hi all, i use:
Distributor ID: neon Description: KDE neon User Edition 5.18 Release: 18.04 Codename: bionic
and i have the same issue, the service stay loaded but never run. When i check the installation status never finish the dpkgof docker-ce, and obviously never start the installation of docker-ce-cli or containerd.io. For the installation i followed the instructions of the official site ([https://docs.docker.com/engine/install/ubuntu/]). I made an upgrade/update of the SO, and tried to repeat the process without results.
Finally i need to remove from dpkg --remove and then install a previously version:
● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enable Drop-In: /etc/systemd/system/docker.service.d └─override.conf Active: active (running) since Tue 2020-04-28 11:08:19 -03; 37s ago Docs: https://docs.docker.com Main PID: 9433 (dockerd) Tasks: 24 CGroup: /system.slice/docker.service └─9433 /usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:2375
Have you tried the moby issue tracker?
Prior to placing the issue, please check following: (fill out each checkbox with a
X
once done)Description of the bug: What kind of issue have you exactly come across?
Last night I updated docker to a newer version using apt update & apt upgrade
Since the update I am not able to send and receive emails. Running
df -h
results in:Usually (at least before updating) the docker containers would show up as mounted filesystems too.
Running
docker container ls --all
results in:This, I guess, means that the containers exist somewhere in my system but they are simply not mounted.
I have also tried restarting (using
docker-compose down && docker-compose up -d
) the mailcow instance but that didn't help either.Results at restart:
Results of docker status:
My issue is...
Reproduction of said bug: How exactly do you reproduce the bug?
Update docker/system to latest using
apt update && apt upgrade
I have tried restarting (using
docker-compose down && docker-compose up -d
) the mailcow instance but that didn't help either.System information
Further information (where applicable):
docker version
)Docker version 19.03.3, build a872fc2
docker-compose version
)docker-compose version 1.24.1, build 4667896b
My observation is: updating docker results in breakage of software. Recommendation: Do not update to Docker 19.03.3
Further notes:
git diff origin/master
, any other changes to the code? If so, please post them.iptables -L -vn
,ip6tables -L -vn
,iptables -L -vn -t nat
andip6tables -L -vn -t nat
Check
docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254
(set the IP accordingly, if you changed the internal mailcow network) anddocker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @1.1.1.1
- output? Timeout?General logs: