Docker Port Konflikt - Port is already allocated - wie löschen?

[3x3cut0r]

Hi
ich habe mehrere Docker Container im Einsatz bei denen dieses Phänomen bereits auftrat.
Ich habe zb. einen Nextcloud Container erstellt der seine internen Ports 80 und 443 auf 2080 und 4080 nach außen öffnet.
Ports die definitiv nicht durch andere Dienste blockiert oder "allocated" wurden.
Der Container lies sich auch erstellen und betreiben.

Irgendwann lies sich der Container auf einmal nicht mehr starten, weil er durch einen Port Konflikt das Starten abbricht. Ich bin nicht ganz sicher wann. Obs nach einem DS Neustart war oder wie auch immer. Auf jeden Fall gibt es bisher außer diesen Container keinen weitern oder irgend etwas anderes was auf diese beiden Ports läuft.

docker: Error response from daemon: driver failed programming external connectivity on endpoint nextcloud (b043aa3c739f05408aca6edae5d9f7e1740d35c16e96e1e26b8338ee50ca76bd): Bind for 0.0.0.0:4080 failed: port is already allocated.

Wenn ich nun den Container lösche und auch die Config-file in dem der Port zugewiesen wird lösche ...

rm /usr/local/etc/services.d/docker_nextcloud.sc

... kann ich den Container nicht wieder erstellen, da immer noch der oben genannte Fehler auftritt.
Erst nach einem DS Neustart ist es wieder möglich.

Wenn ich mit netstat nach offenen Port schaue bekomme ich folgendes:

ash-4.3# netstat -tulpen | grep 4080
tcp6       0      0 :::4080                 :::*                    LISTEN      0          69340      26444/docker-proxy

Meine Frage nun: Wo ist dieser Port noch gemappt?
In der Firewall lässt er sich nach dem der Container gelöscht wurde nicht mal mehr Freigeben.
Wie kann ich den docker-proxy Dienst neustarten ohne jedesmal die ganze DS neuzustarten?

Ist das ein Docker-spezifischer Bug?
Kann ich da etwas machen?

Danke für Anregungen!

 

[Der Paul]

Gibt es einen bestimmten Grund, dass Du über die Shell gehst? Eigentlich sollte Container stop->clean->start wieder alles reparieren (sofern Du nicht auch irgendwelche Container-internen Konfigurationen in dessen Mountverzeichnissen bearbeitet und dadurch ggf korrumpiert hast)

 

[3x3cut0r]

In diesem Fall gibt es keinen Grund nein.
Ist für mich komfortabler als über die GUI ... ich copy und paste meinen Befehl rein und der Container ist mit der gleichen Konfiguration erstellt wie vorher.
Ich mag dieses zusammengeklicke nicht ... die Volumes auswählen usw. ... das ist der einzige Grund.
Außerdem sehe ich über die Console die genaue Fehlermeldung!
Über die GUI kam nur: Docker API hat einen Fehler verursacht und der Container konnte nicht gestartet werden. Oder sowas in der Art.
Also auch über die GUI hatte ich das selbe Verhalten nur ohne genau zu wissen was der Fehler überhaupt ist.
Die Mountverzeichnisse sollten hier nicht das Problem sein.

Gruß

 

[haydibe]

Schau mal mit `docker ps -a`, ob irgendwo ein laufender bzw. nicht laufender Container den Port an sich zieht.
Docker-Proxy ist der Prozess, der für die Kupplung für gemappte Ports zwischen Host und Container verwendet wird, wenn der Kernel zu alt ist und die entsprechende Funktion nicht nativ genutzt werden kann. Er wird jeweils pro Container erzeugt (oder war es pro Mapping?)

Das die Services unter `/usr/local/etc/services.d/` liegen kannte ich noch gar nicht. Die *.sc wird auch nicht für jeden Container erzeugt. Es ist auch nichts was vanila Docker machen würde. Kann es sein, dass es lediglich für Einträge im "Application Portal" ist.

Falls Du Deine Container noch mit `docke run`starten solltest. Schau dir mal docker-compose an, die Deployments sind damit einfacher und vorallem sicherer reproduzierbar.

 

[3x3cut0r]

Nein mit 'docker ps -a' oder 'docker container ls -a' gibt es keinen Container der diesen Port hat!

Also bei mir ist exakt jeder Container der Ports mappt auch unter `/usr/local/etc/services.d/` zu finden. Dieses Verzeichnis kenne ich aus anderen Threads hier.

Ob nun mit 'docker run' (obsolete), 'docker container run' oder 'docker-compose' starte ändert aber nichts am Problem hier.
Und warum sicherer reproduzierbar?
Für mich ist es das selbe nur anders dargestellt, als .yaml File ... und ich mag kein yaml

Gruß

 

[haydibe]

Sicherer im Vergleich zum copy/pasten alle Male.
Sicherer als die Verwendung von Bash-Skripen im Hinblick auf eine Schema-Valdierung auch.

Schon mit `docker system prune -a` mal alles gelöscht was laut Docker nicht genutzt wird?

Sonst mal das Docker Packet deaktivieren. Wenn dann immer noch docker-proxy Prozesse laufen, diese killen, dann das Docker Paket neu starten und erneut versuchen.

 

[helftheo]

Im Verzeichnis /usr/local/etc/services.d entsprechende Datei löschen!

 

[3x3cut0r]

Siehe Post #1 ... das habe ich bereits getan und das hat nicht geholfen. In keiner der Dateien ist der entsprechende Port zu finden!

 

[3x3cut0r]

Ich habe immer noch das selbe Problem. Nun auch mit dem Teamspeak Docker Container.
Nach dem letzten DSM Update und einem Neustart ließen sich Nextcloud und Teamspeak nicht mehr starten, da die Ports bereits blockiert sind.
Und im Verzeichns /usr/local/etc/services.d gibt es keine einzige Datei, die die Ports beinhalten.

Das muss ein Docker interner Fehler sein. Denn die Ports sind nur durch die jeweiligen Container selbst blockiert.
An wen kann ich mich denn hier wenden? Synology oder an Docker?

 

[Ulfhednir]

Doofe Frage: Wie werden denn die Container von dir ausgeführt? Als Bridge? Host? Denkbar, dass sich die Ports mit DSM bzw. einer DSM-Anwendung beißen?

Wenn das nicht hilft: Würde ich bei Synology nachhaken.
Ich meine, dass von Synology eine veraltete Docker-Version verwendet wird. Bevor man dir also bei Docker weiterhilft / weiterhelfen kann, wird die Maßgabe sein, dass die Version aktuell ist.

 

[Benares]

Übrigens, z.B. mit

netstat -anp | grep "LISTEN "

lässt sich relativ leicht herausfinden, welche TCP-Ports bereits belegt sind und durch welchen Prozess.
Diese Ports lassen sich dann natürlich nicht nochmal für einen Container verwenden.

 

[haydibe]

Ich meine, dass von Synology eine veraltete Docker-Version verwendet wird

Die aktuelle CE Version 19.03.12 ist am 18.06.2020 rausgekommen. Das aktuelle Synology Docker Paket basiert auf der CE 19.03.8 Version, die am 10.03.2020 veröffentlich wurde. Als so alt würde ich die Synology-Redistribution jetzt nicht ansehen. Bei QNAP sind sie noch bei 17.09.x (haben dafür andere nette Vorteile und einen ziemlich guten docker-compose support über die UI).

Ulfhednir hat schon recht, irgendein anderer Prozess muss den Port schon binden damit es zum Konflikt kommt. Zu Konflikten kann e s bspw. kommen, wenn man einen Container beendet - aber nicht löscht und dann über die Shell einen neuen mit identischen Parametern anlegt und startet (geht natürlich nur wenn der Containername nicht identisch ist)...

Ich nutze Docker auf der DS schon seit Version 1.0.5 und hatte das Problem NUR, wenn ich versucht habe die vorher exportiere Konfig eines Containers zu importieren, ohne den Alten vorher zu löschen... und das war klar selbstverschuldet von mir.

Schon mal in /var/log/Docker/docker.log (als root) nach Indizien für die Ursache gesucht?

 

[Ulfhednir]

Die aktuelle CE Version 19.03.12 ist am 18.06.2020 rausgekommen. Das aktuelle Synology Docker Paket basiert auf der CE 19.03.8 Version, die am 10.03.2020 veröffentlich wurde. Als so alt würde ich die Synology-Redistribution jetzt nicht ansehen. Bei QNAP sind sie noch bei 17.09.x (haben dafür andere nette Vorteile und einen ziemlich guten docker-compose support über die UI).

Also docker -v zeigt bei mir 18.09.8 auf meiner DS1618+

 

[haydibe]

Ohja... da habe ich wohl auf eine meiner Linux-Kisten geschaut.

Das aktuelle Synology Docker Paket basiert auf der CE 19.03.8 Version, die am 10.03.2020 veröffentlich wurde. Als so alt würde ich die Synology-Redistribution jetzt nicht ansehen

ersetzen durch:

Das aktuelle Synology Docker Paket basiert auf der CE 18.09.8 Version, die am 17.07.2019 veröffentlich wurde. Als so alt würde ich die Synology-Redistribution jetzt nicht ansehen ,

 

[3x3cut0r]

Also ich fasse nochmal zusammen:
Der bereits belegte Port wird von dem Prozess "docker-proxy" benutzt. -> Durch keine andere Anwendung/Paket/oder Container. > !!! ganz sicher !!!<
Das kann ich durch "netstat -tulpen | grep <belegter Port>" sehen
Der Konflikt entsteht wenn der Docker Container unerwartet beendet wurde.
Warum er das tut? ... kann ich nicht feststellen. -> passiert manchmal (meiner Meinung nach) willkürlich nach dem Neustarten der DS oder nachdem sie nicht ordnungsgemäß heruntergefahren wurde und Neugestartet ist.
Beheben kann ich es indem ich den Prozess kille, (evtl den Container lösche), Docker via Paketzentrum stoppe, wieder starte, (evtl den Container neu erstelle) und den Container anschließend starte. Dann läuft er so als wäre nichts gewesen.

Diese Prozedur ist aber äußerst mühseelig und regt mich schon etwas auf, weils einfach unnötig ist.
Ich kann aktuell mit dem Workaround leben aber hätte das schon gerne mal Public gemacht und gelöst irgendwann.

Gruß

 

[haydibe]

Der bereits belegte Port wird von dem Prozess "docker-proxy" benutzt. -> Durch keine andere Anwendung/Paket/oder Container. > !!! ganz sicher !!!<

Je published port eines Containers läuft ein eigener docker-proxy Prozess. Während des Stoppens oder Löschen eines Container werden normalerweise die zugehörigen docker-proxy Prozesse gelöscht und die ip-tables Regeln "glattgezogen". Solche "Verklemmungen", bei dem einzelne Teile des Deployments nicht vollständig abgeräumt sind, bevor ein neues Deployment durchgeführt wird, kenne ich höchsten von docker-compose up bzw. docker stack deploy Deployments... aber dafür gibt es eine Lösung. Die bei deinem Problem aber nicht die Lösung sind.

Warum er das tut? ... kann ich nicht feststellen. -> passiert manchmal (meiner Meinung nach) willkürlich nach dem Neustarten der DS oder nachdem sie nicht ordnungsgemäß heruntergefahren wurde und Neugestartet ist.

Was sagen den die Container-Logs, die Logs in /var/lib/Docker/docker.log und die Ausgabe vom Befehl "dmesg" dazu?

Ich kann aktuell mit dem Workaround leben aber hätte das schon gerne mal Public gemacht und gelöst irgendwann.

Wenn das alles nichts hilft, dann einfach ein Ticket bei Synoogy aufmachen.

 

[mamema]

Also ich fasse nochmal zusammen:

HiHo Leidensbruder/Schwester im Geiste.
Ich habe dasselbe Problem.
Bei mir hat sich das mit zunehmenden Docker Containern gezeigt. Nunja, nicht jeder hat 40 Running Container, so dachte ich, hat das mit irgendwelchen Socket Ressourcen zu tun.
Ich habe das z.B. bei +/- 30 Docker Containern NIE gehabt.
Immer beim starten der DS
Um es spannend zu machen, es ist mal dieser oder mal jener Container. Die Ports haben definitiv keinen Konflikt
Der Hammer war kürzlich: Der Container der via DSM GUI Docker Port Konflikte gemeldet hatte, habe ich zwei Tage "unbeachtet" gelassen. Nichts weiter getan, keinen Reboot. Danach dann mal einen Startversuch. Das Ding startete nun.

Was meine Situation verbessert hat: Ich bin ohne Grund (never Change a running system) mit dem Watchtower Container auf ein neues Image gegangen containrrr/watchtower und auf "clean" d.h. entferne veraltete Images etc.
Das war nicht gut..... Docker insgesamt wurde komplett instabil......

Ich bin dann zurück auf vtec/watchtower (alt aber beserr ) und hab das "clean" rausgenommen.
Putze jetzt regelmässig von Hand mit Portainer.

EDIT: Hier noch angefügt, dass dies KEIN "Dau Fehler" "...der findet die Portkonflikte nicht* Fehler ist, wenn das mal schief hängt, dann kann ich Docker Container erstellen oder starten mit Ports auf "Automatisch" d.h. die Syno nimmt selbst welche im oberen 30xxx Bereich. Es funktioniert nicht, es gibt einen Portkonflikt.

 

[3x3cut0r]

Also wenn du das jetzt so schreibst kann ich nur zustimmen.
Ich habe aktuell 26 Container am laufen. Habe letzt nämlich alles was ging und als Paket lief durch Docker Container ersetzt ... dieses Problem fing erst danach an. Also als die Container in ihrer Anzahl mehr wurden (>20)
Ja es ist tatsächlich spannend weil es jetzt auch bei mir variiert welcher Container es ist. Hatte es nun schon bei 3 verschiedenen.

 

[mamema]

welcher watchtower und welche Parameter hast Du?

 

[mamema]

bin schlauer und steh immer noch dumm da.

Ist wohl ein alter Linux Kernel Bug der immer mal wieder als gefixt gemeldet wird und immer überlebt. Habe das in /var/log/messages gefunden:

unregister_netdevice: waiting for lo to become free. Usage count = 1

gibts quer durch alle Docker benutzenden OS.

Lösung: Reboot.

EINE Meldung gefunden, dass dies hilft:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -w net.ipv4.ip_forward=1 >> /dev/null 2>&1

kann/will ich gerade nicht testen......