[2018/06/20 13:49:40.209923] [18007|18007] Server child process 18009 terminated; uncaught signal: 11 (Segmentation fault)
..... + viele Zeilen mit Verweis auf Files....
Könnten Sie uns bitte genau diese "vielen Zeilen" (den Stacktrace) an support@liveconfig.com schicken? Das könnte Hinweise darauf geben, wo genau das Problem liegt.
Viele Grüße
-Klaus Keppler
Vielleicht liefert der "dmesg"-Befehl hilfreiche Hinweise?
Ansonsten können wir Ihnen da leider auch nicht weiterhelfen - das muss sich ein Admin direkt auf dem Server anschauen.
Der Log-Meldung nach wurde LiveConfig jedenfalls regulär beendet und ist nicht abgestürzt o.ä. - zusammen mit dem Hinweis auf ein langsames System deutet das auf den OOM-Killer hin.
Ich habe jetzt das in der liveconfig Log gefunden.
Das ist eine völlig normale Meldung, wenn LiveConfig beendet wird.
Stellt sich also die Frage, warum LiveConfig beendet wird (bzw. wer das beendet).
Ein Blick in /var/log/messages bzw. /var/log/syslog gegen 06:02:58 könnte da weiterhelfen.
Eine Möglichkeit: ein Backup-Prozess der um diese Zeit läuft, zu viele Ressourcen benötigt und über den OOM-Killer LiveConfig abschießt...
LiveConfig arbeitet überhaupt nicht mit den User-IDs, sondern nur mit den Benutzernamen.
Daher dürfte es auch künftig keine Probleme seitens LiveConfig geben. 
Muss man mehr machen, als die User ID im[INDENT]/etc/passwd
[/INDENT]
ändern
Soweit nicht, da LiveConfig keine User-IDs speichert sonder nur mit den Usernamen arbeitet.
und dann alle Files im Filesystem mittels[INDENT]chown -R 20000:20000 /var/www/web1
[/INDENT]
[INDENT]chown -R 20000:20000 /var/mail/[/INDENT]
NEIN - bloß nicht!
Die Rechte in /var/mail/ müssen gar nicht geändert werden, da die Mails dem Systemuser "mail" gehören.
Bei den Webspaces ist das deutlich differenzierter - einige Verzeichnisse gehören <Vertrag>:www-data, andere <Vertrag>:<Vertrag>, usw.
Der Benutzer darf KEINE Schreibrechte in seinem Homeverzeichnis haben, das muss weiterhin root:root gehören!
Führen Sie einfach das Script "/usr/lib/liveconfig/lcservice.sh fix-permissions [Vertrag]" aus (optional mit einem Vertragsnamen, oder ohne Parameter um alle Webspace-Verzeichnisse durchzugehen).
(am besten im ersten Durchgang mal nur mit einem einzelnen Webspace testen, also z.B. "/usr/lib/liveconfig/lcservice.sh fix-permissions web1")
LiveConfig v2.6.1 is available for download now.
This release contains basically bugfixes and minor improvements.
Anyone using NGINX with LiveConfig should install the upgrade as soon as possible. There was a bug which led to flooded access.log files in many cases.
The changes are:
Ab sofort steht LiveConfig v2.6.1 zum Download bereit.
Es handelt sich dabei hauptsächlich um Bugfixes und kleinere Verbesserungen.
Wer NGINX mit LiveConfig betreibt, sollte dieses Update bitte möglichst zeitnah einspielen. Es gab in dieser Konstellation einen Fehler, der in vielen Fällen dazu führte, dass access.log-Dateien von NGINX-Webspaces voll laufen.
Die Änderungen sind:
Das Update (v2.6.1) ist ab sofort verfügbar. Wer NGINX mit LiveConfig betreibt, sollte das bitte möglichst zeitnah einspielen.
Noch mal ein ehrliches und großes SORRY für die vollgelaufenen Log-Dateien. 
Der Fehler ist auch wirklich äußerst ärgerlich. Um das vielleicht kurz zu erklären: lclogsplit wurde komplett neu entwickelt und arbeitet intern nun vollständig Event-basiert. Dabei erkennt lclogsplit auch, ob Log-Dateien rotiert wurden - und zwar dann wenn sich die inode-Nummer der betroffenen Log-Datei geändert hat oder die Logdatei zurückgesetzt (truncated) wurde. Genau hier gab es einen Fehler, der bei Logfile-Quellen (also nur bei NGINX) in manchen Fällen fälschlicherweise ein "Truncate" bei der Logdatei gemeldet hat - woraufhin diese komplett neu eingelesen und durchgeparsed wurde. Je nachdem wie groß wie Quell-Log-Datei war, führte das dann entsprechend zu viel Output.
Wir planen nun die Testphase vor größeren Änderungen etwas umzustrukturieren, um so etwas früher erkennen zu können. (das NGINX-Log wird z.b. standardmäßig nur wöchentlich rotiert, und der Fehler kann frühestens ab der zweiten Rotation auftreten).
Gab oder gibt es einen Problem mit dem LOGGING ??
In der aktuellen v2.6.0 kann es ein Problem geben, wenn NGINX genutzt wird und die Logrotation zuschlägt. Wir arbeiten daran, Update kommt in den nächsten Stunden.
yesterday I must hard-restart my server, and from that moment,
this problem exist.
Ok, possibly /var/run/ is located on a RAM drive or tmpfs (and thus deleted on restart).
Please create /var/run/liveconfig, then it should work again.
We'll check that lclogsplit cares for this automatically with the next update.
Zitatone more thing, some serious bug lclogsplit have on my server, just nginx web server is there,
but i`l wrote about it later..
We're currently investigating a problem with lclogsplit after NGINX log rotation (log file is periodically re-read from start). Bugfix expected within the next few hours.
Jun 18 10:28:52 web3 systemd[1]: Starting LiveConfig lclogsplit...
Jun 18 10:28:52 web3 lclogsplit[6981]: lclogsplit: pid_create: open: No such file or directory
Jun 18 10:28:52 web3 lclogsplit[6981]: pid_create: open: No such file or directory
Did you modify the location of the lclogsplit PID file (/var/run/liveconfig/lclogsplit.pid)?
Does /var/run/liveconfig/ exist? (owned by root:root, mode=0755)
Was liefert der Befehl
ldd /opt/php-7.0/lib/php/extensions/no-debug-non-zts-20151012/gd.so
zurück?
Ist das Paket "libgd3" korrekt installiert?
Ich tippe mal darauf, dass das Upgrade nicht vollständig durchgelaufen ist und libgd nicht aktualisiert wurde.
Ok... but mode 0654 doesn't make sense, you should use mode=0644.
What Linux distribution do you use?
I've just checked with Debian 9, here the access.log is being created correctly (with mode 0644).
on the webspace page, view log window, access.log is empty
Please restart lclogsplit ("service lclogsplit restart") and then check if the access.log is updated when the website is accessed.
If even after a lclogsplit restart the access.log remains empty, check if the domain name is listed within /var/lib/liveconfig/accesslog.map.
Obwohl ein externer Server eingegeben wurde, versucht sich liveconfig auf ein Socket zu verbinden welches nicht existieren kann. (MySQL Server ist eine externe, gesicherte Anwendung)
[...]
Mit der vorherigen Version (2.5.0) hat dies noch einwandfrei funktioniert!
Mit v2.6.0 wurde der integrierte MySQL-Client durch den MariaDB Connector/C ersetzt. In unserer Testumgebung klappt die Verbindung via TCP/IP zu externen MySQL-Servern aber problemlos.
Welche Distribution genau setzen Sie ein? Können Sie uns ggf. Ihre my.cnf-Datei mal an support@liveconfig.com schicken?
Fehler gefunden: in der Upgrade-Funktion der RPMs wurde nur unter /etc/apache2/ gesucht (OpenSUSE), während CentOS aber /etc/httpd/ verwendet.
Wurde eben mit r4974 korrigiert. Danke für den Hinweis!
nach dem Update startet der Webserver nicht korrekt da die accesslog.map im Ordner /var/lib/liveconfig erwartet wird.
Die scheint sich nun aber im Ordner /etc/httpd zu befinden.
Ich habe ein Symlink au /var/lib/liveconfig erstellt. So ging es erstmal.
Wo muss der Pfad geändert werden?
Umgekehrt: die Datei befand sich offenbar noch in /etc/httpd/, gehört ab v2.6.0 aber in /var/lib/liveconfig.
Ich tippe mal auf CentOS? Welche Version genau?
Eigentlich sollte während des Upgrades die Datei automatisch entsprechend verschoben werden.
Welches Paket genau haben Sie installiert (liveconfig oder lcclient) und auf welcher Distribution genau?
Alles anzeigenwhat about version that are not installed trough liveconfig repository,
custom.lua:
LC.web.addPHP("php53", "/usr/bin/php53/php-cgi")
will it be register?
This will work exactly as before.
Müssen die dafür früher erfolgten Anpassungen an der custom.lua zwingend vor dem Update rückgängig gemacht werden?
Nein, natürlich nicht. Es gibt nur im liveconfig.log einen dezenten Hinweis ("PHP version 'php72' already registered") - mehr passiert nicht.
