Was stimmt nicht mit meiner rc.local-Datei (Ubuntu)?

Question

Ich habe einen Python-Daemon-Prozess, der über rc.local gestartet wird. Dasselbe Skript mit denselben Berechtigungen ist auch auf einigen anderen Ubuntu-Rechnern installiert, die ich habe. Es läuft ohne Probleme auf diesen Installationen. Das heißt, nach einem Neustart des Rechners läuft der Daemon-Prozess.

Bei dieser speziellen Installation läuft der Daemon-Prozess jedoch nicht mehr, wenn ich mich anmelde und die Existenz des Prozesses überprüfe. Die rc.local-Dateien sind auf beiden Systemen identisch (oder zumindest nahe genug dran):

localaccount@sosms:~$ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

python /var/www/myDaemon/Main.py > /var/log/somelog.txt

exit 0

Die Berechtigungen sind:

localaccount@sosms:~$ ls -la /etc/rc.local
-rwxr-xr-x 1 localaccount localaccount 370 Jun  3 11:04 rc.local

Ich habe getestet, ob der Prozess rc.local ausgeführt wird, indem ich diesen Test rc.local verwendet habe:

localaccount@sosms:/var/log/sosmsd$ cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

echo "test" > /home/localaccount/test1
/usr/bin/python /var/www/sosms/sosmsd/Main.py > /var/log/sosmsd/log/log
echo "test" > /home/localaccount/test2

exit 0
localaccount@sosms:/var/log/sosmsd$

Und nur die erste Testdatei (test1) wird nach dem Neustart der Box erstellt. Ich vermute, dass dies bedeutet, dass die Python-Zeile ein Problem verursacht, aber ich erhalte keine Ausgabe in /var/log/sosmsd/log/log:

localaccount@sosms:~$ ls
test1

更新しています：

Ich habe dann den Rat von Larsks befolgt und festgestellt, dass der Fehler beim Starten des Python-Skripts auftrat:

mysql_exceptions.OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)")

Bedeutet dies, dass rc.local ausgeführt wird, bevor MySQL die Möglichkeit hatte, initialisiert zu werden? Was soll ich jetzt tun?

Answer 1

Eine Sache, die andere Leute, die geantwortet haben, übersehen haben, ist, dass in Ihren rc-, init- usw. Skripten, die beim Start ausgeführt werden, die PATH-Variable initialisiert sein kann oder auch nicht (es gibt nie eine Garantie), was bedeutet, dass die einfache Eingabe von "python somescript.py" anstelle von /usr/bin/python nicht immer funktioniert. Verwenden Sie IMMER absolute Pfade für alles in Init-Skripten und rc-Skripten.

Und ja, es ist wahrscheinlich, dass rc.local ausgeführt wird, bevor mysqld gestartet wird. Sie müssen es stattdessen als init.d-Skript einrichten und Kommentare im Stil von insserv im Header verwenden, um ihm mitzuteilen, welche Abhängigkeiten es braucht. http://manpages.ubuntu.com/manpages/lucid/man8/insserv.8.html

Answer 2

Python-Ausnahmen -- und die meisten anderen Fehlermeldungen -- gehen an stderr , aber Sie leiten nur um stdout . Sie sollten Ihren Dienst wie folgt betreiben:

python /var/www/myDaemon/Main.py > /var/log/somelog.txt 2>&1

En 2>&1 sagt der Shell, dass sie Folgendes senden soll stderr Ausgabe an der gleichen Stelle wie stdout . Tun Sie dies und posten Sie alle Fehlermeldungen, die Sie sehen, wenn das Problem nicht offensichtlich ist.

Answer 3

Sie sollten ein Init-Skript erstellen /etc/init.d/mydaemon für Ihren Daemon aus dem verfügbaren Skeleton.

Dann können Sie die Startreihenfolge so festlegen, dass MySQL bereits verfügbar ist.

Hier ist ein gute Ausgangsbasis .

Answer 4

Meine Freunde. Ich habe mehrere Tage für diesen Fehler gebraucht. Zum Glück habe ich eine Lösung gefunden.

sudo -u www -i /the/path/of/your/script

P [...] Die Option -i (simulate initial login) führt die durch den Passwortdatenbankeintrag des Zielbenutzers angegebene Shell als Loginshell aus...

Du kannst vorziehen, was ich hier poste: Skript mit rc.local ausführen: Skript funktioniert, aber nicht beim Hochfahren

Viel Glück!

Answer 5

Aus den mysql-Dokumenten: C.5.2.2. Kann keine Verbindung zum [lokalen] MySQL-Server herstellen

Die Fehlermeldung (2002) Can't connect to ... bedeutet normalerweise, dass kein MySQL-Server auf dem System läuft oder dass Sie einen falschen Unix-Socket-Dateinamen oder eine falsche TCP/IP-Portnummer verwenden, wenn Sie versuchen, sich mit dem Server zu verbinden. Sie sollten auch überprüfen, ob der von Ihnen verwendete TCP/IP-Port nicht von einer Firewall oder einem Port-Blocking-Dienst blockiert wird.

Existiert die Datei "/var/run/mysqld/mysqld.sock"?

Läuft der mysql-Server auf demselben Server wie der Python-Daemon-Prozess?

Haben Sie sich das mysql-Protokoll angesehen?

Es sollte sich befinden in /var/log/

Der Name lautet etwa so:
mysql.log
mysql.err
mysqld.log
mysqld.err

$ sudo ls -l /var/log/
// when you have the name try
$ sudo tail -n 50 /var/log/LogName

Eine Möglichkeit ist, dass Sie keinen Speicherplatz mehr haben, versuchen Sie es:

$ sudo df -h

Sehen Sie sich die 4. Spalte "Avail" an.

Eine andere Möglichkeit sind die Ordnerberechtigungen, versuchen Sie es:

$ sudo ls -l /var/lib/

Sie sollten etwa so aussehen:

drwxr-xr-x 33 mysql     mysql   4096 May 22 10:02 mysql

Wahrscheinlich wollen Sie, dass der Besitzer und die Gruppe "mysql" sind, wenn das nicht der Fall ist, können Sie es versuchen:

$ sudo chown -R mysql:mysql /var/lib/mysql

Notieren Sie sich zunächst die ursprünglichen Einstellungen, damit Sie sie wieder ändern können, wenn sie nicht helfen. Das "-R" bedeutet, dass der Eigentümer rekursiv für die Unterordner und Dateien geändert wird.

Die Berechtigungen sollten rwxr-xr-x (755) sein, wenn nicht, können Sie es versuchen:

$sudo chmod 755 /var/lib/mysql

Ich würde das nicht rekursiv machen, die meisten Dateien und Ordner sollten nur für den mysql-Benutzer zugänglich sein, möglicherweise für die mysql-Gruppe und nur lesend/schreibend, nicht ausführbar.