Die Hoffnung stirbt zuletzt, aber sie stirbt.
Wie hast Du das ermittelt?
Ich wuerde nach wie vor empfehlen, das was wir schreiben zu lesen und auch zu beantworten wenn wir was fragen, sonst kann Dir naemlich niemand hier helfen.
Welche Probleme hab ich bisher auch noch nirgends gelesen, es ist die Aufgabe von unoconv zu arbeiten, den wuerde ich dann nicht abschiessen in der Hoffnung, dass dann alles tut.
Ich frag gerne nochmal, Holger hat ja auch mehrmals gebraucht um herauszufinden, dass Du Dich um die workers gekuemmert hast, Antwort seh ich nach wie vor keine ausser „ich hoffe, dass ich das weiter oben schon erwähnt habe.“
Wir helfen Dir gerne, meine Lust geht dann aber irgendwann gegen Null, wenn mein Gegenueber nicht auf die Hilfe eingeht und einfach so weiter vor sich hindackelt.
In anderen Foren waerst Du dafuer schon an die Wand genagelt worden, da siehst Du mal, wie nett die Teilnehmer hier sind.
Da ich keine Infos bekomme, geb ich noch ein paar Tipps und bin dann zumindest mal aus diesem Fred raus.
Vielleicht mal mit iotop schauen, was da auf der Platte ackert, mit iftop ob da was die Netzwerkkarte dichtmacht, mit nethogs, welcher Prozess dann dafuer zustaendig ist…ich koennte da jetzt eine Stunde weitertippen, aber das bringt uns irgendwie auch nicht zum Ziel.
Das ist uebrigens der zweite Fred wo ich bei Dir ausgestiegen bin, ich hab aber auch nicht die Geduld der anderen hier.
der Fehlercode 1 bedeutet „already running“ - das deutet zusätzlich darauf hin, dass unoconv nicht richtig läuft. Du solltest also mal folgendes testen:
Den unoconvd-Prozess stoppen und dann sicherstellen, dass keine Prozesse übriggeblieben sind. Sicherheitshalber auch mal den Webserver stoppen.
unoconv auf der Konsole direkt testen, also ohne Listener
unoconv auf der Konsole mit Listener testen
Einen Unoconvd-Dienst starten und dann nochmal unoconv testen.
wie meinst Du das - ich dachte, wenn ein Listener läuft, dann wird der automatisch genutzt? Der Mechanismus ist doch so: Wird unoconv aufgerufen, checkt es, ob ein Listener läuft. Wenn ja, wird er genutzt. Wenn nein, wird einer gestartet, verwendet und anschließend beendet. Genau deshalb gibt es ja eventuell Probleme, wenn mehrere Dokumente gleichzeitig ohne Listener konvertiert werden.
ich habe das auch so verstanden, wie Du es erklärt hast.
Aber Tatsache ist, dass es bei uns (Moodle 3.8) auch ohne Listener gut tut ! Bis auf das .jpeg-Problem, das ich jetzt mal angehen muss…andere Baustelle…
Immerhin hat meine Nebenhölenentzündung meine Erinnerung nicht getrübt. Ich habe die Information, wenn auch beiläufig gegeben:
„Maxworkers“ wurden vervierfacht → 400 bei apache2 und mariadb
25 Prozesse und die waren „statisch“. Normalerweise variiert die Anzahl der Prozesse je nach Workload. In der Situation als Moodle eingefroren war, blieb die Zahl konstant. Als ich sie alle gegillt habe lief das System.
Wie schon erwähnt erscheint die Systemmlast im Allgemeinen unauffällig. Ich werde die Tools aber mal ausprobieren.
Auch das werde ich ausprobieren. Obwohl unoconv alles konvertiert, was ich ihm vorsetze. Auch JEPG
Sobald der Server wieder probleme macht: Heute, Morgen, Übermorgen. Arbeite ich Eure Vorschläge ab. Es sei denn, es passiert in unserer Kernzeit des Unterrichts 8-14 Uhr, dann muss ich neustarten, denn die Arbeit unserer 800 Personen hat Priorität.
Hier ein Screenshot von htop während rund 150 Personen auf das System zugreifen - das System läuft flüssig:
heute ist Moodle wieder eingefroren und da die reguläre Schulzeit zu Ende war, hatte ich die Muße, alle Tips abzuarbeiten, ohne dass mir aufgeregte Kollegen im Nacken saßen.
Zunächst einmal ein paar Screenshots von htop mit Filter auf die üblichen Verdächtigen.
Worauf hin die Bash unbenutzbar wurde und ich mich mit einer zweiten SSH-Verbindung erneut einwählen musste. Damit erscheint fast sicher, dass unoconv der Übeltäter ist. Ich habe jetzt das System neu gestartet.
Aber welche Konsequenzen ziehe ich aus den Daten? Die nächsten Vorschläge, sofern ich noch nicht alle Leser unbeabsichtlicht verprellt habe, kann ich dann ausprobieren, wenn das System zu „verträglichen“ Zeiten abschmiert.
stammen die htop Angaben aus der Lastzeit, also wo es gerade
problematisch war?
Teste mal deinen apache mit dem von mir erwähnten apace2buddy script!
Das brigt wirklich Erkentnisse (deutlich weniger, weil du neu gestartet
hast … aber besser als nix).
Wenn du dir so sicher bist, dass es unoconv ist, dann schreib doch mal,
wie das installiert ist (listener?), dann das listener startscript und
die Versionsnummern von
Serverbetriebsystem
unoconv
ghostscript (gs)
php
libreoffice
ganz im Gegenteil: jetzt solltest Du weiter bei unoconv testen. Mit und ohne laufendem Dienst. Wenn das schon im Terminal nicht läuft, dann wird es auch aus Moodle heraus wohl eher nix.
@baumhof: Ja alle Informationen wurden während des Frierens gewonnen.
Als zusätzliche Info: Bevor meine User zu Moodle weitergeleitet werden, erscheint eine einfache php-Seite mit Infos zu unserer Schule. Diese Seite wird auch dann schnell ausgeliefert, wenn Moodle nicht mehr reagiert. Also der Apache und sein PHP scheinen nicht direkt betroffen zu sein.
Vielen Dank. Ich arbeite beide Vorschläge (in zufälliger Reihenfolge) heute Abend ab.
Sehe ich ähnlich, solange die „Info-Seite“ auch:
auf dem gleichen Server wie Moodle liegt
gleiche php-Version/Prozess nutzt
auf gleiche (Sub)-Domain liegt
Bin wirklich gespannt ob und warum unoconv der Verursacher ist.
Wieso letzte Loesung, reinstall geht immer.
Wurde ja oben schon geschrieben, wenn das auf der Kommanozeile nicht tut, kann Moodle das auch nicht nutzen.
Vielleicht ist auch nur die Platte voll oder so’n Scheiss.
Pythons Versionshoelle koennte auch noch Ursache sein - Python suckt manchmal schon.
Tja, wusste gar nicht dass auch nginx auf dem System ist
sudo apt install --reinstall unoconv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
dnsutils libevent-2.1-6 libgnutls-dane0 libirs161 liblockfile1 libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo
libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter
libnginx-mod-mail libnginx-mod-stream libunbound8 lockfile-progs nginx-common nginx-full sendmail-base sensible-mda
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 155 not upgraded.
1 not fully installed or removed.
Need to get 50.0 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirror.eu.oneandone.net/debian buster/main amd64 unoconv all 0.7-1.1 [50.0 kB]
Fetched 50.0 kB in 0s (1,974 kB/s)
(Reading database ... 104604 files and directories currently installed.)
Preparing to unpack .../unoconv_0.7-1.1_all.deb ...
Unpacking unoconv (0.7-1.1) over (0.7-1.1) ...
Setting up nginx-full (1.14.2-2+deb10u3) ...
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nginx, action "start" failed.
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2021-02-03 21:18:08 CET; 15ms ago
Docs: man:nginx(8)
Process: 20408 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 20411 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=1/FAILURE)
Feb 03 21:18:06 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Feb 03 21:18:06 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
Feb 03 21:18:07 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Feb 03 21:18:07 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
Feb 03 21:18:07 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Feb 03 21:18:07 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
Feb 03 21:18:08 deb10.lernplattform-nordeifel.de nginx[20411]: nginx: [emerg] still could not bind()
Feb 03 21:18:08 deb10.lernplattform-nordeifel.de systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Feb 03 21:18:08 deb10.lernplattform-nordeifel.de systemd[1]: nginx.service: Failed with result 'exit-code'.
Feb 03 21:18:08 deb10.lernplattform-nordeifel.de systemd[1]: Failed to start A high performance web server and a reverse proxy server.
dpkg: error processing package nginx-full (--configure):
installed nginx-full package post-installation script subprocess returned error exit status 1
Setting up unoconv (0.7-1.1) ...
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
nginx-full
E: Sub-process /usr/bin/dpkg returned an error code (1)
hast Du denn mit und ohne den zugehörigen Dienst getestet? Und vor allem: Mehrere Dokumente gleichzeitig, idealerweise von sehr unterschiedlicher Größe? In der Anleitung ist ja sehr deutlich beschrieben, wo es potentiell klemmen kann.