owncloud: Fehlermeldung PHP Startup: No such handler: DBA_DEFAULT at Unknown#0

[kerku]

Hallo zusammen,

gestern habe ich die angebotenen Paketaktualisierungen (u.a. Webstation, MariaDB und PHP5.6) durchgeführt.

Nun finde ich folgende Fehlermeldungen im owncloud-Protokoll:
PHP Startup: No such handler: DBA_DEFAULT at Unknown#0
(owncloud-Version ist 9.1.2)

Bislang habe ich nicht viel hierzu finden können, und auch hier im Forum bislang nur diesen Beitrag, in dem das Thema am Rande gestreift wird:
http://www.synology-forum.de/showthread.html?81992-nach-Update-für-php7-fehlende-Module/page2

Ausserdem noch dieses hier:
http://stackoverflow.com/questions/41484672/owncloud-server-dba-default-php-error
Allerdings verstehe ich die 2 Antworten nicht wirklich:
Antwort #1:
So one solution is to ensure that your application is invoking the correct Php version. For this you can manage the HTTP server and PHP version from the Synology Web Station.

-> Laut Einstellungen in der Administration der Webstation wird PHP 5.6 genutzt. PHP 7 ist nicht installiert.

Antwort#2:
I have changed /volume1/@appstore/Apache2.2/usr/local/etc/apache22/conf/extra/mod_xsendfile.conf
from
XSendFilePath /var/services/web /var/services/homes
to
XSendFilePath /volume1/owncloud

->könnte ich ausprobieren. Wüßte aber vorher gerne, in welchem Zusammenhang das steht?

Zusätzlich irritiert mich, dass die owncloud nun offenbar wieder unter dem Apachen 2.2 läuft. War der Webserver nicht mal per Default auf Nginx gewechselt worden (Installiert ist beides)?

In den PHP-Einstellungen der Webstation gibt es die Möglichkeit, die Erweiterung "dba" zu deaktivieren. Wäre das die korrekte Option, um die Fehlermeldung zu beseitigen?

Die owncloud funktioniert ansonsten offenbar einwandfrei. Ich finde Fehlermeldungen grundsätzlich nur immer etwas beunruhigend

Sorry, falls meine Angaben zu dürftig sind. Falls benötigt, liefere ich alles Gewünschte nach...
(Und ja stimmt - ich habe nicht wirklich Ahnung von der Materie. Konnte mich bislang aber immer ganz gut durchbeißen...)

Danke + Gruß
Kerku

 

[Fusion]

Auf der Syno laufen 2 webserver. Der Sys und der User Webserver. Der Sys webserver ist seit einiger Zeit nginx und läßt sich auch nicht ändern. Der user webserver ist Standard auch auf nginx, kann aber für vHosts auf Apache umgestellt werden.
Owncloud kriegst du auf der DS auch (ohne größeren Nacharbeiten) nur unter Apache ans Laufen.

xsendfile hat mit dem Thema eigentlich nichts zu tun, das war glaube ich im Zusammenhang mit Dateien, die dann nicht angeschaut oder heruntergeladen werden konnten weil die Links zu den Files nicht gepasst haben.
Wieso das bei dem einen Kollegen geholfen haben soll (oder wie).... gute Frage. Aber versuchen kann mans ja mal.
/volume1/owncloud macht auch gar keinen Sinn, weil das bei einer Standard-Installation gar nicht vorhanden ist. Also fraglich was er da gemacht hat (data Ordner ausgelagert etc.). Aber selbst dafür brauche ich den Eintrag nicht mehr seit owncloud 9 / nextcloud 10.

Den dba Eintrag bei den PHP Einstellungen kannst du ausschalten, dann verschwindet die Fehlermeldung.
Berkeley DB kommt mit owncloud ja nicht zum Einsatz.
Irgendwo in owncloud bzw. dem vHost (der bei mir auch unter php56 läuft) wird anscheinend doch noch auf die normale php Umgebung zugegriffen, in der das dba Modul nicht aktiviert ist.
Steht ja auch so in dem Link zu Stackoverflow.
Kanns bis jetzt auch nicht richtig nachvollziehen, weil auch eine info.php direkt im vHost aufgerufen die richtige Umgebung liefert mit passenden dba Eintrag.

 

[kerku]

Hallo Fusion,

vielen Dank erst mal für die schnelle Antwort!

Einen vhost hatte und habe ich gar nicht eingerichtet, und laut Update-Protokoll ist der Apache 2.2 auch erst gestern wieder installiert worden (warum auch immer - wahrscheinlich gab es irgendwelche Abhängigkeiten?)
Bis gestern müsste also auch die owncloud unter nginx gelaufen sein. (Da ich die owncloud immer zu Fuß update, hatte ich mir als Befehl notiert, den Webserver nginx zu beenden und neuzustarten: "synoservicectl --start nginx". Bis irgendwann voher war es mal der Apache).

Die phpinfo im /web-Verzeichnis zeigt mit auch den Pfad an: /usr/local/etc/php56 mit aktiviertem dba-support.
Interessanterweise hat die php.ini im Verzeichnis /usr/local/etc/php56 ein Änderungsdatum von gestern und auch der von mir selbst im letzten Jahr eingetragene Wert "always_populate_raw_post_data = -1" im Abschnitt

 ist nun nicht mehr da, weshalb nun zusätzlich auch prompt die Meldung 
[I]"Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. at Unknown#0" [/I] im owncloud-Protokoll wieder auftaucht,

Das ist alles schon recht seltsam.

Im Moment kann ich mit den Meldungen erst einmal leben, allerdings wäre mir wohler, ich würde die Ursachen und Lösungen verstehen :-)

 

[Fusion]

Der Apache war auch vorher noch drauf (für Inhalte die unter /web liegen), er war nur kein separates Paket. Das hast du nur nicht gesehen deshalb.

Falls es bei dir doch nginx gewesen sein sollte würde mich deine config interessieren, weil es direkt aus dem zip oder web-installer bei mir unter nginx nicht starten wollte.
Wann / unter welchen DSM Version hast du denn owncloud initial installiert?

Für raw_post_data habe ich das auch noch in /usr/syno/etc/packages/WebStation/php56/php.ini unter General neben der von dir erwähnten Datei. Aber möglich, dass beide bei einem Update der Web Station überschrieben werden.

 

[kerku]

Die owncloud installiert hatte ich ursprünglich noch unter DSM 5.x. Das ist gut 2 Jahre her. Dann kam irgendwann DSM 6.x und ich musste den Befehl zum Neustarten des Webservers anpassen, weil der alte nicht mehr tat. Da hatte ich irgendwo gelesen, dass der Apache durch nginx ersetzt worden sei (wahrscheinlich hier im Forum?).
Welche config interessiert dich? Die der owncloud oder die vom Webserver? (Letztere wüsste ich jetzt mal nicht zu finden, aber ich würde suchen... ;-))

 

[Fusion]

Die vom webserver. Aber wenn du da nichts angepasst hast und "suchen" musst, dann wird das die Standard config gewesen sein.
Und da du von 5.2 kamst wird da der Apache im Hintergrund mit übernommen (auch wenn der webserver restart über nginx lief)
Nur bei DSM 6 Neuinstallation läuft von Anfang an erstmal beides auf nginx (und der Apache wird trotzdem im Hintergrund noch bereit gehalten).
Wie du siehst gibt es eben nicht den webserver, deshalb ist auch Wechsel Apache > Nginx nicht allgemein gültig von jetzt auf gleich.

Den Beweis muss ich allerdings schuldig bleiben, da ich meine Test-DS gerade nicht zur Hand habe um das nochmal nachzustellen und auch zu sehen, ob es vielleicht einen Unterschied zwischen OC 9.1.3 und NC 10.0.1 gab, was die nginx Fähigkeit anging.
Die Kombi die ich zuletzt hatte und die nicht out of the box lief war eben NC 10.0.1, DSM 6 frisch installiert (keine Upgrade), nginx user-webserver.

 

[kerku]

Vielen Dank erst mal für die aufschlussreichen Antworten! Beweisen musst du sicherlich nichts - das klingt alles recht nachvollziehbar ;-)

Leider werde ich mich diese Woche nicht weiter damit beschäftigen können. Aber danach werde ich mal versuchen, die Fehlermeldungen durch die erneuten Eintragungen in der php.ini (an beiden von dir genannten Orten) wegen dem RAW_POST_DATA und das Deaktivieren von bda in den Einstellungen von php wegzubekommen.
Ich werde dann hier posten, ob es geholfen hat.

 

[Tom80]

Hallo,

Habe heute diese Fehlermeldung auch das erstemal bei meiner Nextcloud 11.0.1 gesehen.
Würde mich interessieren ob des bei Dir geholfen hat.

Tom

 

[kerku]

Auch Hallo

Ja, ich habe just heute abend beides über die Administration in der DSM / Web Station konfiguriert:
1. Über PHP-Einstellungen die Erweiterung "dba" deaktiviert
2. PHP-Einstellungen / Erweiterte Einstellungen / Kern - hier den Wert bei "always_populate_post
_data" auf "-1" gesetzt.
Hier habe ich nun noch nicht kontrolliert, in welcher php.ini sich das niederschlaägt. Scheinbar gibt es ja mindestens zwei Orte.

Bislang sind beide Meldungen verschwunden.

 

[Tom80]

Danke, Fehlermeldung scheint weg zu sein!
Werde das die Tage aber noch beobachten.

Tom

 

[kerku]

Nur zur Ergänzung:
Das ""always_populate_post_data=-1" steht in keiner der beiden php.ini
(/usr/syno/etc/packages/WebStation/php56/php.ini und /usr/local/etc/php56) sondern in der user_settings.ini:
/usr/syno/etc/packages/WebStation/php56/conf.d/

Soll mir auch recht sein

 

[OdinsAuge]

Hallo, ich habe ebenfalls den Fehler PHP Startup: No such handler: DBA_DEFAULT at Unknown#0

Apache 2.2 und php5.6 sind eingestellt.
Das dba modul ist eigentlich aktiviert.

 

[Fusion]

Dass das dba Modul aktiv ist und eben der DBA_DEFAULT Wert nicht gesetzt ist, ist eben genau, was die Meldung auslöst.
Normal kannst du das Modul deaktivieren.
Oder du setzt dein Log-Level auf ein passenderes Niveau.

 

[OdinsAuge]

Achso, ich brauch das modul gar nicht?

Ich hab hier eine ANtwort dazu gefunden:
http://stackoverflow.com/questions/41484672/owncloud-server-dba-default-php-error

Ich versteh nicht ganz, im Paketzentrum ist php 5.6 installiert, aber die DiskStation benutzt als Standard irgend eine andere PHP Version.
KKann mich da wer Aufklären? warum 2 php Versionsn (von denen ich eine nicht installiert hab und sie auch nicht sehen kann außer in der command line)

 

[Fusion]

Es laufen ja auch mehrere Webserver auf der DS, ebenso kann man beliebige PHP Versionen installieren.
Was am Ende benutzt wird ist Sache der Konfiguration..
Da Synology für den Teil unter dem z.B: der DSM läuft weniger häufig Anpassungen vornehmen will, als es Updates gibt für Pakete ist das eben getrennt

Je nachdem, was man für Webanwendungen betreiben will kann man ja auch vHosts mit verschiedenen PHP Versionen betreiben wollen.
Im DSM siehst du eben nur die die du selber beeinflussen kannst

 

[rednag]

Dass das dba Modul aktiv ist und eben der DBA_DEFAULT Wert nicht gesetzt ist, ist eben genau, was die Meldung auslöst.
Normal kannst du das Modul deaktivieren.

Ich habe das jetzt 14 Tage getestet. DBA unter Erweiterungen in der Web Station deaktivert. Der Fehler bleibt der gleiche.

 

[kerku]

@rednag:
Bei mir ist der Fehler bzgl DBA_DEFAULT seit der Deaktivierung nicht mehr aufgetreten. (PHP 5.6 + Apache 2.2)

 

[rednag]

Das ist ja interssant. Mein Log ist voll wegen der Fehlermeldung, owwohl DBA deaktiviert war.
Auch in dem gleichen Setting.

 

[kerku]

Nun habe ich noch mal ein wenig herumgesucht und bin auf folgende Dinge gestoßen:
In dem hier nun schon mehrfach verlinkten Eintrag http://stackoverflow.com/questions/41484672/owncloud-server-dba-default-php-error wird ja gesagt, dass der Befehl "root@synology:~# /usr/local/bin/php56 --ri dba" die unterstützten (supporteten) handlers ausgibt.
Das sind wohl "gdbm cdb cdb_make db4 inifile flatfile".

Nach dieser Seite hier: http://php.net/manual/en/ini.list.php ist der per Default eingetragene Wert eigentlich leer.

Meine Vermutung ist nun schlicht, dass der Wert "DBA_DEFAULT" eben deswegen einen Fehler produziert, weil es tatsächlich einen handler namens "DBA_DEFAULT" nicht gibt. Oder dieser eben irgendwo sonst noch spezifiziert werden müsste, welcher der oben genannten der Default-Handler denn sein soll.
Eine alternative Lösung könnte also sein, den Wert z.B. auf "flatfile" zu ändern, wie es der Kommentator "deusexmac" im Link oben ja auch getan hat. Scheinbar mit Erfolg.

Für mich ist es ok, die Erweiterung dba zu deaktivieren, weil ich sie offenbar nicht benötige. Aber falls es sonst niemand testen möchte, täte ich es mal probieren

 

[Tom80]

@rednag:
Bei mir ist der Fehler bzgl DBA_DEFAULT seit der Deaktivierung nicht mehr aufgetreten. (PHP 5.6 + Apache 2.2)

Bei mir ist der Fehler seither auch weg!