Skip to content
View in the app

A better way to browse. Learn more.

Froxlor Forum

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

[solved] libnss error with apache

Featured Replies

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!

- 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.

  • 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.

  • 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

Joa MySQL sollte vor libnss und Apache starten. Da musste mal schauen wie dein system sowas handhabt. Welche distro nutzt du denn?

  • 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?

Klar versucht er es immer wieder. Die Frage nach deiner Distribution hast du immernoch nich beantwortet

  • Author

Sorry ich nutze Debian Wheezy. Und wenn ich mich nicht t?usche, dann tritt der Fehler jetzt nicht mehr auf ...

  • 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 ...

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?

  • 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 ...

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.

  • 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. :)

  • 1 year later...
  • 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!

  • 2 years later...

Klappt so bei mir nicht :)

On 6.10.2017 at 1:59 PM, mind said:

Klappt so bei mir nicht :)

Dieser Thread ist DREI Jahre alt...

  • 2 months later...
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.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.