Debian nextcloud und phpmyadmin Fehler

ChAiN SaW

Lieutenant
Registriert
Apr. 2011
Beiträge
946
Servus,

ich habe vor kurzem nextcloud auf meinem Debian vServer installiert, nach Anleitung 1 und Anleitung 2. Das hat auch alles wunderbar funktioniert, bis ich heute ein "apt-get update && apt-get dist-upgrade && apt-get autoclean" durchgeführt habe.

Nun bekomme ich beim aufrufen von nextcloud eine weiße Seite und phpmyadmin bringt beim anmelden folgenden Fehler.
822481


Ich habe mich auch probiert über putty einzuloggen, hier bekomme ich diesen Fehler:

Code:
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Der Ordner mysqld existiert aber auch nicht, Allgemein ist diese mysqld.sock nirgends zu finden.

Wie bekomme ich es nun hin, das nextcloud und phpmyadmin wieder laufen?
Auch ist mir aufgefallen das ich den apache2 mit systemctl start apache2 per Hand starten musste und das nicht automatisch nach dem Neustart passiert ist.
 
Läuft MySQL denn?
Code:
mysqladmin -u root -p status
bzw.
Code:
systemctl status mysql


Und mit
Code:
sudo find / -type s
findest du alle Socket Files, vielleicht findest du die mysqld.sock datei. :)
 
mysqladmin -u root -p status
Code:
root@:~# mysqladmin -u root -p status
Enter password:
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

systemctl status mysql
Code:
root@:~# systemctl status mysql
Unit mysql.service could not be found.

sudo find / -type s
Code:
root@:~# sudo find / -type s
/tmp/xarchiver_root_socket
/tmp/ssh-LsVenvkEw1Dw/agent.1206
/tmp/.ICE-unix/1250
/tmp/.X11-unix/X0
/root/.gnupg/S.gpg-agent
/root/.gnupg/S.gpg-agent.browser
/root/.gnupg/S.gpg-agent.ssh
/root/.gnupg/S.gpg-agent.extra
/run/containerd/containerd.sock
/run/minissdpd.sock
/run/avahi-daemon/socket
/run/acpid.socket
/run/dbus/system_bus_socket
/run/uuidd/request
/run/user/0/bus
/run/user/0/gnupg/S.gpg-agent.ssh
/run/user/0/gnupg/S.gpg-agent.extra
/run/user/0/gnupg/S.dirmngr
/run/user/0/gnupg/S.gpg-agent
/run/user/0/gnupg/S.gpg-agent.browser
/run/user/0/systemd/private
/run/user/0/systemd/notify
find: ‘/run/user/113/gvfs’: Permission denied
/run/user/113/bus
/run/user/113/gnupg/S.gpg-agent.browser
/run/user/113/gnupg/S.gpg-agent
/run/user/113/gnupg/S.dirmngr
/run/user/113/gnupg/S.gpg-agent.extra
/run/user/113/gnupg/S.gpg-agent.ssh
/run/user/113/systemd/private
/run/user/113/systemd/notify
/run/systemd/journal/syslog
/run/systemd/journal/dev-log
/run/systemd/journal/socket
/run/systemd/journal/stdout
/run/systemd/private
/run/systemd/cgroups-agent
/run/systemd/notify
/run/systemd/inaccessible/sock
/run/udev/control
 
  • Gefällt mir
Reaktionen: konkretor
Sorry, der Dienst heißt wohl mysqld.
Versuch damit den Dienst zu starten. Falls es nicht geht, probier es im Safe-Mode.
 
Ich glaube eher, das alte MySQL wurde beim upgrade entfernt weil es nicht mehr dabei ist. Aktuell wird MariaDB verwendet (dessen Dienstname aber weiterhin mysql ist weil Fork).

Du hast aktuell scheinbar keine Datenbank installiert.

apt-get install mariadb-server

... sollte das Problem beheben. Keine Angst, deine Datenbank ist nicht weg, die wird dann von MariaDB bedient.
Die liegt unter /var/mysql/...
 
Bei den beiden Anleitungen werden distributionsfremde Pakete und nicht-Debian Webquellen installiert.

Außerdem werden bei
ChAiN SaW schrieb:
apt-get dist-upgrade && apt-get autoclean
dem Autoclean die heruntergeladenen Pakete gelöscht.
Ein Rückkehr zu der alten funktionierenden Version wird so erschwert.
Dazu kann dist-upgrade Pakete löschen.
Die Logdateien von apt bzw. dpkg helfen bei den deinstallierten/gelöschten Paketen weiter.
Ob auf den Servern die alten funktionierenden deb Pakete noch liegen musst du selbst prüfen.

Bei Webservern mit Paketen aus Drittquellen sollte das Update vielleicht aus Sicherheitsgründen nicht so stark automatisiert werden - Konfigurationsdateien können sich ändern.

Externe Pakete gehen sehr leicht kaputt - deshalb können Pakete geschützt werden: Prevent updating of a specific package.
 
  • Gefällt mir
Reaktionen: guzzisti
Vielleicht weils "Fremdsoftware" aus einer anderen Quelle war und als inkompatibel eingestuft im Upgrade Prozess ....
 
Okay, wir müssen also die Glaskugel schütteln:
Du hast ein Debian installiert (welche Version?) und dann ein Dist-Upgrade gemacht auf eine neue Version? Ich rate mal: von 9 auf 10? In Debian 10 ist der mysql server raus geflogen und wurde durch mariadb ersetzt.

Ansonsten: Backup einspielen und das Dist Upgrade erneut durchführen und uns mal die Ausgaben hier posten welche Pakete er aktualisieren will und welche ggf. deinstalliert wurden.
Ergänzung ()

@lokon Im besten Fall nutzt man aber gar nicht erst fremde Paketquellen, zumindest nicht solange es Alternativen in den Repos der jeweiligen Distribution gibt. Wer doch so etwas machen will sollte sich eben auch über die Konsequenzen im klaren sein und damit umzugehen wissen.
 
  • Gefällt mir
Reaktionen: guzzisti
Es ist ein Debian 9. MariaDB ist schon seit einem Jahr auf der Kiste installiert und auch immer mit oben genannten Befehl aktuallisiert wurden. Nur diesmal scheint es selbige beim updaten gelöscht zu haben. Da es nach erneutem installieren wieder funktionierte. An sowas hatte ich gar nicht gedacht weil das eigentl nicht passieren sollte.
 
snaxilian schrieb:
Im besten Fall nutzt man aber gar nicht erst fremde Paketquellen
Ja - es hat bestimmt auch Gründe weshalb phpmyadmin in Buster "obsolete" ist. - Zeit ist wohl ein Grund (Debian Tracker). Oder es nextcloud nicht "nativ" gibt.
Für einige sind dann Container die Lösung anstelle von nativer Installation. Oder eine Rolling Distribution, wenn aktuellere Pakete wichtiger sind. - Beide Empfehlungen vielleicht off-Topic.
Allerding hat der Ersteller einen Debian vServer und ist deshalb vielleicht in der Kompatibilität / Unterstützung eingeschränkt.
 
Dann muss man eben die Software direkt vom Entwickler nutzen. Bei irgendwelchen Fremd-Repos von Dritten bist du gnadenlos ausgeliefert wenn jemand Viertes das Repo übernimmt, du weißt nicht ob der Ersteller des Fremd-Repos regelmäßig Updates einpflegt oder ggf. nicht gewollte sonstige Software einschleust.
Ja, das Problem hat man theoretisch auch bei jedem Repo einer Distribution aber diese Projekte gibt es ja schon ein wenig und werden von mehr als einer Person betreut. Wenn man einzelnen unbekannten Dritten im Internet blind vertrauen mag kann man das schon so machen.
Gleiches gilt in identischer Art und Weise für irgendwelche Docker Images vom öffentlichen Docker Hub. Da kann auch jeder ein Image hochladen. Ob und wie man diese nutzt sollte man sich immer genau überlegen.
 
snaxilian schrieb:
Da kann auch jeder ein Image hochladen.
Früher sagte man immer: "Was auf der Straße rumliegt, hebt man nicht auf."
Genau aus dem Grund, dass man nicht weiß wer das schon alles in der Hand hatte und auf der Straße kann ja auch mal schnell was dreckig und keimig werden.

Das gilt offenbar im Internetzeitalter alles nicht mehr. Da wird von überall aus der Jauchegrube Internet runtergeladen was das Zeug hält und kaum einer macht sich ein Kopf.
 
  • Gefällt mir
Reaktionen: snaxilian und lokon
"nativ" = Damit sollte eine Verfügbarkeit über den Debian Paketmanager gemeint sein.

Nextcloud listet im Server Administration Manual auch bestimmte Versionen und Konfigurationen auf, die benötigt werden. Außerdem kann es irgendwelche Distributionsbesonderheiten geben, die Kompatibilität einschränken und dann durch automatisches Installieren der korrekten Abhängigkeiten, Konfigurationsfiles gelöst werden könnten.
 
Zurück
Oben