Mysqld.sock wird nicht mehr gefunden

[Andreas_Stein]

Hallo zusammen,

ich habe mal wieder ein Problem. Heute morgen stand eine eGroupwareinstallation (21.1-7.4, keine Reaktion mehr auf Anmeldeseite). Zuerst fiel mir auf, das die Festplatte vollgelaufen war. Der Ordner /var/lib/docker/containers enthielt über 100GB.
das größte LOG-File …-json.log (70GB) mit truncate auf 0 gesetzt. - VM neu gestartet
docker logs -f egroupware liefert:

/usr/bin/php7.4 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --update 'all,admin,;Hd?H8RmvQL5azG0’
EGroupware API version 21.1.001 found.
EGroupware configuration file (header.inc.php) version 1.29 exists and is up to date
Your database is not working! mysqli://egroupware:G-1V]pJjm|4[|wwZ@localhost/egroupware:
/usr/share/egroupware/setup/inc/class.setup_cmd.inc.php (312)

Die Datenbank ist MariaDB 10.1 und lief tatsächlich nicht. Nachdem ich in /etc/mysql/mariadb.conf.d/50-server.cnf den Eintrag “log_bin = /var/log/mysql/mysql-bin.log” auskommentiert habe, lief die Datenbank wieder (warum auch immer!), und ist per webmin voll zugreifbar.

Bei “docker-compose up -d” bekomme ich aber nun die Fehlermeldung:

ERROR: for egroupware Cannot start service egroupware: failed to create shim: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting “/var/run/mysqld/mysqld.sock” to rootfs at “/var/run/mysqld/mysqld.sock”: mount /var/run/mysqld/mysqld.sock:/var/run/mysqld/mysqld.sock (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

und eGroupware startet nachtürlich nicht. Und die mysqld.sock ist auch vorhanden.

Hat jemand noch eine Idee, was ich machen könnte?
viele Grüße
Andreas

[Andreas_Stein]

Hallo,

Problem gelöst !!!
docker-compose down
rm -r /var/lib/docker/containers/*
docker-compose pull
docker-compose up -d
alles wieder gut!

viele Grüße
Andreas

[RalfBecker]

Ja wenn der Socket, der per Bind-Mount in den Container gegeben wird, nicht existiert legt Docker dafür eine leeres Verzeichnis an

Deswegen ist unsere Empfehlung und Default auch eine Datenbank im Container zu verwenden. Das hat nur Vorteile und keine Nachteile. Wenn man will kann man des Port auch für den Host freigeben und so z.B. mit den gewohnten MySQL Tools darauf zugreifen. PhpMyAdmin gibt es von uns ja auch als Container, um mal in der Datenbank etwas machen zu können.

Ralf[

[Andreas_Stein]

Hallo zusammen,

leider habe ich mich zu früh gefreut. Das ursprüngliche Problem - Platte läuft voll - besteht leider immernoch.
Mittlerweile habe ich die Installation upgedatet auf 23.1.20230824, und hatte gehofft, das der Fehler damit behoben ist. Der Fehler besteht darin, das aktuell in dem 67a78acbc35cd8f39ded1caf6954a66d64ce48e7404b5628ab59ea2deb4a1cd6-json.log im gleichnamigen container mehrere hundert Einträge pro Sekunde generiert werden, und zwar immer sich wiederholende Blöcke wie dieser:

{“log”:“wsd-00001-00001 2023-09-10 19:06:51.338302 +0000 [ coolwsd ] TRC Checking pid for jail 1 /opt/cool/child-roots/| common/JailUtil.cpp:224\n”,“stream”:“stderr”,“time”:“2023-09-10T19:06:51.338778152Z”}
{“log”:“wsd-00001-00001 2023-09-10 19:06:51.338337 +0000 [ coolwsd ] DBG Removing [/opt/cool/child-roots/1-cf8ae485/tmp] recursively.| common/FileUtil.cpp:269\n”,“stream”:“stderr”,“time”:“2023-09-10T19:06:51.338959703Z”}
{“log”:“wsd-00001-00001 2023-09-10 19:06:51.338350 +0000 [ coolwsd ] DBG Removing [/opt/cool/child-roots/1-cf8ae485/linkable] recursively.| common/FileUtil.cpp:269\n”,“stream”:“stderr”,“time”:“2023-09-10T19:06:51.339077539Z”}
{“log”:“wsd-00001-00001 2023-09-10 19:06:51.338360 +0000 [ coolwsd ] DBG Unmounting [/opt/cool/child-roots/1-cf8ae485]| common/JailUtil.cpp:85\n”,“stream”:“stderr”,“time”:“2023-09-10T19:06:51.339188208Z”}
{“log”:“wsd-00001-00001 2023-09-10 19:06:51.338368 +0000 [ coolwsd ] TRC Executing coolmount command: /usr/bin/coolmount -u /opt/cool/child-roots/1-cf8ae485| common/JailUtil.cpp:36\n”,“stream”:“stderr”,“time”:“2023-09-10T19:06:51.339264905Z”}

leider kann ich mir da keinen Reim drauf machen, was da fehlt bzw. ursächlich ist.
Gibt es dazu eine Idee?

viele Grüße
Andreas

[StefanU]

/opt/cool/child-roots/

Das ist Collabora Online.

Wie sieht da deine Installation aus?
Steht ein Paket-Update aus?
Läuft/funktioniert COOL bei dir?
…

Was meint ein
docker ps -a

Stefan

[Andreas_Stein]

Hallo Stefan,

jetzt weiß ich zumindest mal, woher es kommt. Collabora Online wird bei mir gar nicht benutzt - jedenfalls nicht vorsätzlich. COOL gibt es gar nicht. docker ps -a liefert (unter anderen):

67a78acbc35c quay.io/egroupware/collabora-key:stable “/start-collabora-on…” 4 days ago Up 34 seconds 127.0.0.1:9980->9980/tcp collabora-key

die Nr. entspricht auch dem Container, der Ärger macht. Ich habe jetzt unter /etc/egroupware-collabora-key/ (da war ich noch nie!) mit docker-compose down den Container mal gestoppt, und unter …/egroupware/setup collabora bei den Anwendungen deaktiviert. Jetzt ist alles ruhig.-) und ich kann die Brechstange (1 mal pro Stunde “find /var/lib/docker/containers/ -name ‘*-json.log’ -exec truncate -s 0 {} ;”) wieder weglegen.

vielen Dank für die Hilfe und viele Grüße
Andreas

[StefanU]

Collabora Online wird bei mir gar nicht benutzt

Schade…
https://help.egroupware.org/t/de-uk-folien-vortrag-slides-lecture-froscon-2021-egroupware-und-collabora-online-in-der-praxis/76179

COOL

Collabora Online = COOL

mit docker-compose down den Container mal gestoppt

Der wird so bei nächsten reboot wieder Starten
Schau mal in die docker-compose.yml
Da steht sicherlich:
restart: always

Wenn du die Datei kopierst nach
docker-compose.override.yml
dort alles auskommentierst und den Parameter auf no (meine ich…) setzt, sollte der Container beim nächsten reboot nicht mehr gestartet werden.

unter …/egroupware/setup collabora bei den Anwendungen deaktiviert.

Kann man machen… Vorzugsweise aber einfach nur die Ausführungsrechte entziehen.

Stefan

[Andreas_Stein]

Hallo Stefan,
danke für den Tip

Wenn du die Datei kopierst nach

docker-compose.override.yml

dort alles auskommentierst und den Parameter auf no (meine ich…) setzt, sollte der Container beim nächsten reboot nicht mehr gestartet werden.

danke für den Tip - war notwendig und hat funktioniert.

viele Grüße
Andreas