January 26, 201412 yr Hey,I installed froxlor a few days ago and now I got this error:If I restart the server, SOMETIMES (but often) apache2 isn't starting. In syslog there are the following error: named[2082]: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) start-stop-daemon: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) apache2: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) nscd: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) The password and username are right! But: if I start apache2 manually with root-user. Maybe there is a privileg problem?!How I can solve this problem?Thank you for your help!
January 26, 201412 yr - did you try to use 'localhost' instead of '127.0.0.1' ? - why is restarting such a problem, servers don't reboot that much - even updates on linux don't need a server-reboot.
January 26, 201412 yr Author Yes, I tried 127.0.0.1. And sometimes I need a reboot, and it is annoying to restart apache manually ... P.S.: I have the same problem with postgrey. The port can not be found because postgrey isn't running.
January 26, 201412 yr Author named[2075]: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) Jan 26 20:44:49 v22014012001216640 start-stop-daemon: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) Jan 26 20:44:49 v22014012001216640 start-stop-daemon: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) das hier startet unmittelbar nach dem kernel ... da liegt schon mal das erste problem. Zudem startet apache anscheinend VOR mysql, was ja nicht sein sollte: Jan 26 20:44:51 apache2: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) Jan 26 20:44:52 /usr/sbin/cron[2375]: (CRON) INFO (pidfile fd = 3) Jan 26 20:44:52 /usr/sbin/cron[2376]: (CRON) STARTUP (fork ok) Jan 26 20:44:52 /usr/sbin/cron[2376]: (CRON) INFO (Running @reboot jobs) Jan 26 20:44:53 kernel: [ 11.988849] ip_tables: (C) 2000-2006 Netfilter Core Team Jan 26 20:44:53 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
January 27, 201412 yr Joa MySQL sollte vor libnss und Apache starten. Da musste mal schauen wie dein system sowas handhabt. Welche distro nutzt du denn?
January 27, 201412 yr Author Ok, habe jetzt mal ganz neuinstalliert und jetzt gibt es nur noch den Fehler mit nscd. Der Dienst startet einfach zu fr?h, mysql ist noch nicht bereit. Jan 27 19:57:43 v22014012001216640 nscd: libnss-mysql: Connection to server '127.0.0.1' failed: Can't connect to MySQL server on '127.0.0.1' (111) Versucht nscd aber eh immer wieder mit mysql zu verbinden oder?
January 28, 201412 yr Klar versucht er es immer wieder. Die Frage nach deiner Distribution hast du immernoch nich beantwortet
January 28, 201412 yr Author Sorry ich nutze Debian Wheezy. Und wenn ich mich nicht t?usche, dann tritt der Fehler jetzt nicht mehr auf ...
January 29, 201412 yr Author Leider wieder der Fehler -.- Und ich habe NICHTS herumgestellt. Habe das Problem nun so behoben - w?rde gerne wissen, ob das unsauber ist?! - LSBInitScripts von Apache und nscd ver?ndert. Und zwar habe ich bei 'Required Start' die Variabel 'mysql' angeh?ngt. Nun l?uft es nach mehrmaligen Neustarten bis lang problemlos. Habe danach nat?rlich die neuen init.d's eingelesen: insserv apache2 insserv nscd EDIT: Habe jetzt auch bind9 dazugenommen, da der ja auch mysql braucht ...
January 30, 201412 yr Kann ich dir nicht sagen, ob das 100% die korrekte vorgehensweise ist - mit der Startreihenfolge der Services hat froxlor eigentlich nichts zu tun und es klappte bisher immer wunderbar. Benutzt du irgendein komisches System oder testing-pakete oder sowas in der art?
January 31, 201412 yr Author Nein, ich habe das "ganz normale" Debian Wheezy installiert. Und auch nur die Dienste, die Froxlor ben?tigt. Mit meiner Methode hat aber auch heute der Neustart von meinem Provider nach einem technischen Fehler problemlos geklappt. Alles l?uft - ohne Fehlermeldungen. Ich muss wahrscheinlich ggf. die init.d-Dateien nach einem Upgrade von Apache/Bind9 wieder neu erstellen, aber vielleicht brauche ich das ja dann nicht mehr. Das Problem ist eben, dass die Dienste zu fr?h starten. Wenn MySQL noch nicht bereit ist, kann es auch nicht funktionieren, da sich fast alle Dienste, die Daten aus der MySQL-Datenbank holen ...
January 31, 201412 yr Das ist halt Sache des Systems / der Runlevel-Verwaltung. Da kann Froxlor selbst jetzt wenig machen. Kann ich dir auch leider nicht viel weiterhelfen, denn "normal" ist das alles korrekt bei neuen Systemen - zumindest bei denen die ich bisher alle aufgesetzt habe.
January 31, 201412 yr Author Ok, danke jedenfalls! Habe das jetzt so gel?st - bis jetzt funktioniert es auch wunderbar und vielleicht wird das Problem ja mit einem Update behoben.
February 6, 201511 yr Author So um nochmal das Thema korrekt abzuschlie?en - auch wenn es schon mehr als ein Jahr alt ist. Man kann die Abh?ngigkeiten der Start-Scripten ?ndern und zwar folgenderma?en (am Beispiel von capisuite): /etc/init.d/capisuite: #! /bin/sh ### BEGIN INIT INFO # Provides: capisuite # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Capisuite daemon ### END INIT INFO ... INIT INFO kopieren (inkl. Zeilen davor) --> /etc/insserv/overrides/capisuite: #! /bin/sh ### BEGIN INIT INFO # Provides: capisuite # Required-Start: $remote_fs $syslog capiutils # Required-Stop: $remote_fs $syslog capiutils # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Capisuite daemon ### END INIT INFO (ACHTUNG NUR DER LSB-HEADER!) dann insserv [-v] Der Vorteil von dieser Methode ist, dass die original Scripten nicht ver?ndert werden und evtl. bei Updates ?berschrieben werden. Wichtig ist das Ausf?hren von insserv nach den ?nderungen!
October 8, 20178 yr On 6.10.2017 at 1:59 PM, mind said: Klappt so bei mir nicht Dieser Thread ist DREI Jahre alt...
December 26, 20178 yr On 8.10.2017 at 10:37 AM, d00p said: Dieser Thread ist DREI Jahre alt... Das stimmt, aber das Problem ist deswegen noch nicht behoben. Bei mir lief es jahrelang einwandfrei, bis ich von Debian Wheezy auf Jessie ge-upgraded habe. Zwar ist das kein großes problem, nach einem "service php5-fpm start" läuft der Server wieder und ich habe das jetzt locker ein Jahr so gelassen. Auf dauer ist es aber doch nervig, da nach einem Kernel-Upgrade auch mal ge-rebooted werden sollte und 'Downtime' generell nicht wünschenswert ist. Das Problem wird sichtbar mit dem Befehl ls -l /etc/rc*.d Die hier gezeigten Dateien werden auf Reihenfolge der Dateinamen abgearbeitet. In der folgenden Datei habe ich eine Zeile hinzu gefügt, um das Problem zu lösen: /etc/init.d/mysql ... # Should-Start: $network $time # Should-Stop: $network $time # X-Start-Before: php5-fpm mysql nscd dovecot courier-authdaemon courier-pop postfix bind9 opendkim proftpd apache2 courier-imap # Default-Start: 2 3 4 5 ... dann ein: insserv -v #Wer viel 'von Hand' am System gebastelt hat sollte hier vielleicht die vorsichtigere Variante nehmen mit: "update-rc.d mysql defaults" Jetzt sollte ein wiederholtes "ls -l /etc/rc*.d" die richtige Reihenfolge anzeigen und nach einem Reboot alles wieder laufen. Eines ist mir bei der Suche nach dem Problem noch aufgefallen. Die datei: "/etc/libnss-mysql-root.cfg", ist für den MySQL-root-User! Wenn mann in Eile die von Froxlor vorgeschlagenen Configs durch geht, dann übersieht man das schnell und übernimmt -wie ich- hier die Froxlor-Zugangsdaten. Nach der Korrektur dieser Datei blieb das Problem allerdings bestehen und ich kann momentan nicht sagen inwiefern Probleme dadurch enstanden sind. Vielleicht hilft es ja noch jemandem, LG
Archived
This topic is now archived and is closed to further replies.