!Friendica Support
Ich bekomme von beim Starten von Cron für worker.php ständig Fehlermeldungen:
PHP Notice: Undefined index: Psr\Log\NullLogger in /var/www/virtual/hiker/fri.bitcast.info/vendor/level-2/dice/Dice.php on line 134
Was ist da los?
Ich bekomme von beim Starten von Cron für worker.php ständig Fehlermeldungen:
PHP Notice: Undefined index: Psr\Log\NullLogger in /var/www/virtual/hiker/fri.bitcast.info/vendor/level-2/dice/Dice.php on line 134
Was ist da los?
Das Problem hatte ich vor zwei Wochen auch plötzlich, siehe hier.
Kurzfristige "Lösung": von PHP 7.4 auf PHP 7.3 switchen. Da aber 7.3 meines Wissens nicht mehr supportet wird, keine wirkliche Lösung.
Andere "Lösung": hinten an den cron-Job "> /dev/null 2>&1" anhängen, das sendet alle Fehlermeldungen ins Nirvana. Besser als alle paar Minuten eine Mail zu bekommen, aber Du erfährst nichts mehr von Fehlern, die evt wirklich etwas bedeuten.
Kurzfristige "Lösung": von PHP 7.4 auf PHP 7.3 switchen. Da aber 7.3 meines Wissens nicht mehr supportet wird, keine wirkliche Lösung.
Andere "Lösung": hinten an den cron-Job "> /dev/null 2>&1" anhängen, das sendet alle Fehlermeldungen ins Nirvana. Besser als alle paar Minuten eine Mail zu bekommen, aber Du erfährst nichts mehr von Fehlern, die evt wirklich etwas bedeuten.
PHP-Notice-Mail bei jedem Worker-Lauf nach PHP-Update
Hallo !Friendica Support , einem Beitrag von uberspace entnehme ich, dass dort eine neue PHP-Version eingespielt wurde. Seit heute bekommen ich mit jedem Wo...dica.interfel.de
This entry was edited (1 year ago)
Roland Häder likes this.
@Bionk Genau - der Fehler ist plötzlich bei einer laufenden Installation aufgetreten und ja, mit Workaround mit /dev/null habe ich die Fehlermeldungen vorerst unterbunden.
@Hiker@Bionk Wuerde ich nicht machen, da dies echte Fehler auch unterdrueckt und das eigentliche Problem somit immer noch besteht. Bei mir laeuft der Worker als Daemon. Einfach mit
./bin/daemon.php start starten. Die ueblichen Kommandos stop und status werden auch supportiert. Dann brauchst du keine Umleitung nach /dev/null nicht, was ja problematisch und nicht wirklich eine Loesung (sondern - richtig erkannt - nur ein Workaround ist), weil dann solch Fehlermeldungen vom Worker auch nicht mehr kommen.Bionk likes this.
@Roland Häder Genau so und solange, bis die Ursache gefunden und hoffentlich behoben ist. Aber die Flut der Emails (in der Cron-Zeit) musste ich mal abstellen.
like this
@Hiker Ich kann deine Entscheidung nachvollziehen. Hast du schon meinen anderen Tipp ausprobiert? Also dass du
vendor neu aufbauen laesst?@Roland Häder Ich habe die
https://friendi.ca/resources/download-files/
stable Version nicht per git, sondern via Dateien installiert - da gibts kein ./bin/composer.pharhttps://friendi.ca/resources/download-files/
Roland Häder likes this.
@Hiker Ah, okay. Bitte gucke mal nach der beanstandeten Datei. Auf meinem lokalen System habe ich folgendes:
Sind bei dir aehnliche Rechte fuer Dateien (0644 sollte okay sein) und Verzeichnisse (0755) gesetzt? Eventuell liegt es auch daran, dass einfach das Leserecht fehlt (nicht einfach ueberall 0777 setzen).
quix0r@daedalus:~/NetBeansProjects/friendica$ ls -l vendor/psr/log/Psr/Log/
total 36
-rw-r--r-- 1 quix0r quix0r 3104 May 3 2021 AbstractLogger.php
-rw-r--r-- 1 quix0r quix0r 96 May 3 2021 InvalidArgumentException.php
-rw-r--r-- 1 quix0r quix0r 297 May 3 2021 LoggerAwareInterface.php
-rw-r--r-- 1 quix0r quix0r 402 May 3 2021 LoggerAwareTrait.php
-rw-r--r-- 1 quix0r quix0r 3114 May 3 2021 LoggerInterface.php
-rw-r--r-- 1 quix0r quix0r 3415 May 3 2021 LoggerTrait.php
-rw-r--r-- 1 quix0r quix0r 336 May 3 2021 LogLevel.php
-rw-r--r-- 1 quix0r quix0r 707 May 3 2021 NullLogger.php
drwxr-xr-x 2 quix0r quix0r 4096 May 3 2021 Test
quix0r@daedalus:~/NetBeansProjects/friendica$Sind bei dir aehnliche Rechte fuer Dateien (0644 sollte okay sein) und Verzeichnisse (0755) gesetzt? Eventuell liegt es auch daran, dass einfach das Leserecht fehlt (nicht einfach ueberall 0777 setzen).
@Hiker Okay, das Schreibrecht fuer die Gruppe kannst du mit
Damit sind diese poteniellen Fehlerquellen ausgeschlossen (Ausschlussverfahren von moeglichen Fehlerquellen). Nun faellt mir nichts weiteres mehr ein, was das Problem loesen kann, ausser dass auf seitens Friendica das herunterladbare Archiv neu macht.
chmod g-w problemlos entfernen, da es nicht erforderlich ist. Leserecht und Ausfuehr-/Durchsuchrecht (x fuer Verzeichnisse ist also vorhanden.Damit sind diese poteniellen Fehlerquellen ausgeschlossen (Ausschlussverfahren von moeglichen Fehlerquellen). Nun faellt mir nichts weiteres mehr ein, was das Problem loesen kann, ausser dass auf seitens Friendica das herunterladbare Archiv neu macht.
Ich habe habe/dev/nul selbst aus diesen Gründen auch nicht gesetzt. Es hilft halt akut, wenn alle paar Minuten eine Mail kommt.
Verständnisfrage: beim Betrieb als Daemon müssten doch die gleichen Fehlermeldungen ausgeworfen werden. Kommen die Mails durch den Aufruf via cron und ich finde die Fehler sonst nur im log?
Verständnisfrage: beim Betrieb als Daemon müssten doch die gleichen Fehlermeldungen ausgeworfen werden. Kommen die Mails durch den Aufruf via cron und ich finde die Fehler sonst nur im log?
Roland Häder likes this.
@Bionk Sicher ist das nur ein temporaerer Fix. 
Zu deiner Verstaendnisfrage, das haengt von den Einstellungen in der
Zu deiner Verstaendnisfrage, das haengt von den Einstellungen in der php.ini der CLI-Version von PHP ab, die sehr unterschiedlich sind. Typische Schreibziele fuer das Logbuch sind syslog (meistens geht dies nach /var/log/syslog) und ein eigenes Logbuch, dass in der Einstellung error_log gesetzt ist. Der Standartwert ist hier leer, damit landet es in die Standartausgabe (oder auch Fehlerausgabe stderr?). Sobald du also den Shell-Zugriff beendest, landen die Fehlermeldungen dann im Nirvana (sind weg).; Log errors to specified file. PHP's default behavior is to leave this value
; empty.
; http://php.net/error-log
; Example:
;error_log = php_errors.log
; Log errors to syslog (Event Log on Windows).
;error_log = syslog
Roland Häder likes this.
das muss ich mir erst einmal entkusseln.Die verursachende Zeile 134 lautet
return $this->instances[$name];anscheinend wird irgendein Instanzen-Name nicht initialisiert?
Roland Häder likes this.
@Hiker ist das eine bestehende Installation oder eine neue? Mit welcher Quelle hast du die Installation durchgeführt? Per GIT oder per stable Archiv unter https://files.friendi.ca/friendica-full-2021.09.tar.gz ? Hast du manuell installiert oder automatisch? Sind irgendwelche Addons aktiv?
Der Fehler kann aus meiner Sicht nur auftreten, wenn die Datenbank "frisch" initialisiert wird bei einer Durchführung (= Start des Cronjobs) und er dabei vorher nicht die NullLogger Instanz erzeugt hat .. Aber mir ist derzeit schleierhaft, wie diese Situation überhaupt enststehen kann, da Dice genau das verhindern sollte.
Der Fehler kann aus meiner Sicht nur auftreten, wenn die Datenbank "frisch" initialisiert wird bei einer Durchführung (= Start des Cronjobs) und er dabei vorher nicht die NullLogger Instanz erzeugt hat .. Aber mir ist derzeit schleierhaft, wie diese Situation überhaupt enststehen kann, da Dice genau das verhindern sollte.
Roland Häder likes this.
@Philipp Holzer Bei mir ist es ja die gleiche Situation: gleiche Fehlermeldung bei Installation aus den stable-Archiven.
Meine Instanz lief schon mit der vorangegangenen stable und wurde dann auf 2021.09 aktualisiert.
Meine Instanz lief schon mit der vorangegangenen stable und wurde dann auf 2021.09 aktualisiert.
@Philipp Holzer Gibt es Logbuecher von dem Build der Archive? Kannst du dort reingucken? Eventuell mal den Build-Prozess manuell (Shell) starten und beobachten, was passiert, wenn
composer install --no-dev ausgefuehrt wird (sollte doch, damit vendor mit Leben gefuellt wird).@Roland Häder Woher kommt bei dieser Installation denn dieses "Leben"? Per Download?
Roland Häder likes this.
@Hiker@Philipp Holzer
vendor wird beim Bauen des Archives, dass dur dir vom Server heruntergeladen hast, mit Leben befuellt, indem der Befehl ./bin/composer.phar install --no-dev ausgefuehrt wird und mit in's Archiv getan wird.Philipp Holzer likes this.
@Roland Häder das ist das Archiv, mit dem ich auch das Dockerfile befülle & strukturell identisch auch mit den laufenden DEV-Snapshots, die ich bei opensocial.at als auch bei friendica.philipp.info verwende.
Hab auch eben das stable nochmal ausgecheckt und per composer erneut installiert --> ich bekomme keinen Fehler
@Hiker interessant wäre, ob du mit dem neuesten
Hab auch eben das stable nochmal ausgecheckt und per composer erneut installiert --> ich bekomme keinen Fehler
@Hiker interessant wäre, ob du mit dem neuesten
2021.12-rc Archiv noch immer diese Probleme hast, weil der Release Candidat ist kurz vor der Release.Roland Häder likes this.
@Michael Vogel Was sagst du? Soll @Hiker besser upgraden? Ich kann den Fehler weder unter 2021.09 noch unter 2021.12-rc nachstellen...
Das Problem tritt bei @Hiker und mir offenbar nur unter PHP 7.4.27 auf. Bei mir mutmaßlich nach einem entsprechenden PHP-Update bei Uberspace.
@Philipp Holzer mit welcher Version hast Du das getestet?
@Philipp Holzer mit welcher Version hast Du das getestet?
Roland Häder likes this.
@Paulo da Silva Vollkommen klar, das es keine Lösung ist, daher die "..". Aber es verschafft etwas Ruhe für weitere Nachforschungen.
Hier den Link noch einmal ohne redir, dann sollte er lesbar sein. Er zeigt auf eine ähnliche Fehlerbeschreibung von mir samt dem PHP-Hinweis. Zwei Wochen alt, da gab es keine weiteren Diskussionen.
Ich wollte nur auf das mehrfache "spontane" Auftreten de Fehlers hinweisen und einen mutmaßlichen Zusammenhang mit der PHP-Version herstellen, denn er trat meines Wissens nach einem Update auf PHP 7.4.27 beim Hoster auf.
Nun steht die nächste Friendica stable an, ich werde also updaten und dann auf PHP 7.4 zurück switchen und wenn der Fehler dann immer noch Auftritt, dann lohnt sich eine eingehendere Untersuchung.
Hier den Link noch einmal ohne redir, dann sollte er lesbar sein. Er zeigt auf eine ähnliche Fehlerbeschreibung von mir samt dem PHP-Hinweis. Zwei Wochen alt, da gab es keine weiteren Diskussionen.
Ich wollte nur auf das mehrfache "spontane" Auftreten de Fehlers hinweisen und einen mutmaßlichen Zusammenhang mit der PHP-Version herstellen, denn er trat meines Wissens nach einem Update auf PHP 7.4.27 beim Hoster auf.
Nun steht die nächste Friendica stable an, ich werde also updaten und dann auf PHP 7.4 zurück switchen und wenn der Fehler dann immer noch Auftritt, dann lohnt sich eine eingehendere Untersuchung.
PHP-Notice-Mail bei jedem Worker-Lauf nach PHP-Update
Hallo !Friendica Support , einem Beitrag von uberspace entnehme ich, dass dort eine neue PHP-Version eingespielt wurde. Seit heute bekommen ich mit jedem Wo...dica.interfel.de
Paulo da Silva likes this.
@Bionk Hier ist auch PHP Version 7.4.27 installiert - scheint tatsächlich einen Zusammenhang zu gegeben.
Damit hat sich dann das Problem vielleicht ja gelöst. 😀
https://friendi.ca/2022/02/06/friendica-2022-02-released/
https://friendi.ca/2022/02/06/friendica-2022-02-released/
Roland Häder likes this.
@Bionk Hast du ein Update gemacht? Bin auch bei Uberspace... läuft aber nicht. Wieder zurück zur alten Version.
Bin gerade dabei. Vor zwei Minuten (19:30 Uhr) ist der erste /bin/worker.php nach dem Update gelaufen und es sieht soweit gut aus.
Ich bin noch auf PHP 7.3 und es kam keine Mail vom CronJob.
Mit "uberspace tools version use php 7.3" solltest Du auch auf diese Version switchen können und bräuchtest dann /dev/null nicht.
Ich probiere gleich mal die PHP 7.4 und melde mich dann noch einmal.
Ich bin noch auf PHP 7.3 und es kam keine Mail vom CronJob.
Mit "uberspace tools version use php 7.3" solltest Du auch auf diese Version switchen können und bräuchtest dann /dev/null nicht.
Ich probiere gleich mal die PHP 7.4 und melde mich dann noch einmal.
Update auf 2022.02 erfolgreich durchgeführt, das Datenbankupdate auf 1449 ist inzwischen auch durch.
Ich arbeite mit den Archiven und ohne git.
@Michael Vogel Autsch, beim testweise Umschalten auf PHP 7.4 kommt nun ein 500 Internal Server Error
Nach dem Zurücksetzen auf PHP 7.3 funktioniert alles wieder wie es soll.
@Hiker Versuche es mal mit
"uberspace tools version use php 7.3"
Ich arbeite mit den Archiven und ohne git.
@Michael Vogel Autsch, beim testweise Umschalten auf PHP 7.4 kommt nun ein 500 Internal Server Error
Nach dem Zurücksetzen auf PHP 7.3 funktioniert alles wieder wie es soll.
@Hiker Versuche es mal mit
"uberspace tools version use php 7.3"
...habe mal den Browser-Cache gelöscht und es auch mit diversen anderen Browsern auf dem Desktop und dem Smartphone probiert: Bei PHP 7.4 kommt immer der 500er-Error.
Hiker likes this.
@Bionk Ich habe da noch andere Dinge laufen - weiss nicht, wie die mit dem Umschalten auf 7.3 reagieren...
Zurück in der alten Version, erster Versuch mit Upgrade gescheitert - obwohl .htaccess kopiert wurde, endet der Aufruf im Error 500. Muss das Log File genauer ansehen..
Evtl. werde ich heute nochmal einen Versuch für ein Upgrade starten... Aber das Audröseln des syslog, um den Fehler zu suchen, motiviert mich nicht wirklich.
Kann man bitte mal nachsehen, wo das Problem mit der aktuellen Version von Friendica mit PHP 7.4.27 liegt - Upgrade auf die aktuelle Version 2022.02 ist nicht möglich.
Hier noch ein Log - irgend Probleme mit Dice
https://put.fedcast.ch/mez03ked
Ich kann leider nicht zurück auf PHP 7.3, sonst laufen andere Applikationen nicht mehr.
https://put.fedcast.ch/mez03ked
Ich kann leider nicht zurück auf PHP 7.3, sonst laufen andere Applikationen nicht mehr.
This entry was edited (11 months ago)
Ja ok, habe mal auf php mal auf Version 8.0 gestellt - Friendica hat Update gemacht. Muss jetzt noch schauen, ob die anderen Applikationen mit php 8.0 umgehen können...
@Hiker Und, wie läuft es mit PHP 8.0?
Offenbar hat Uberspace am Donnerstag die Version 7.3 abgeschaltet, so das dieses Fallback nun entfällt.
Nachdem meine Instanz ein paar Tage down war, habe jetzt mal auf PHP 8.1 geswitched nun läuft es endlich wieder.
Apache- und PHP-Logs zeigen erstmal keine Aufflälligkeiten.
Offenbar hat Uberspace am Donnerstag die Version 7.3 abgeschaltet, so das dieses Fallback nun entfällt.
Nachdem meine Instanz ein paar Tage down war, habe jetzt mal auf PHP 8.1 geswitched nun läuft es endlich wieder.
Apache- und PHP-Logs zeigen erstmal keine Aufflälligkeiten.
Das ist total seltsam. Grob gesagt:
Kannst du mal schauen, ob du die Datei findest mit PHP 7.4:
Die müsste er eigentlich laden .. und die ist eigentlich auch nicht unbedingt sehr komplex :D
- Friendica kann keine Instanz für
\Psr\Log\NullLoggererstellen - Darum nimmt es die LoggerFactory
- Aber die LoggerFactory kann erst aufgerufen werden, wenn die Datenbank da ist --> darum auch initial der NullLogger
Kannst du mal schauen, ob du die Datei findest mit PHP 7.4:
vendor/psr/log/Psr/Log/NullLogger.phpDie müsste er eigentlich laden .. und die ist eigentlich auch nicht unbedingt sehr komplex :D
@Philipp Holzer Bin nicht ganz sicher, was Du meinst.
Die Datei vendor/psr/log/Psr/Log/NullLogger.php ist vorhanden und hat die Rechte 644 (rw-r--r--).
Ich vermute, dass ich sie mit
In PHP 7.3 kommt diese Meldung
Die Datei vendor/psr/log/Psr/Log/NullLogger.php ist vorhanden und hat die Rechte 644 (rw-r--r--).
Ich vermute, dass ich sie mit
php vendor/psr/log/Psr/Log/NullLogger.phpaufrufen soll.
In PHP 7.3 kommt diese Meldung
[16-Feb-2022 00:15:22 Europe/Berlin] PHP Fatal error: Uncaught Error: Class 'Psr\Log\AbstractLogger' not found in /var/www/virtual/snila/html/vendor/psr/log/Psr/Log/NullLogger.php:13In PHP 7.4 kommt dagegen diese Meldung
[16-Feb-2022 00:17:49 Europe/Berlin] PHP Fatal error: Cannot declare class Psr\Log\NullLogger, because the name is already in use in /var/www/virtual/snila/html/vendor/psr/log/Psr/Log/NullLogger.php on line 0
/vendor/, wofuer Friendica nicht verantwortlich ist. Ich weis auch nicht, wieso bei dir der Fehler kommt (welche Branch nutzt du? Ich habe hierdevelopim Einsatz.