vServer schreibt keine Logfiles mehr

5

5ky

New Member
Morgen,

wie im Titel schon erwähnt, schreibt einer meiner Debian 6 Server (EasySCP) die Logfiles seit knapp 3 Wochen nicht mehr. auth.log, mail.log, syslog etc. Stehen alle auf Anfang November.

Ich habe schon diverse Untersuchungen angestellt, konnte keine sonderlichen Auslastungen oder laufende Prozesse erkennen.
In den Crontabs sind auch keine anderen Einträge.
Mit Maldet konnte auch nichts gefunden werden.

Ich vermute dass es mit dem gescheiterten Versuch, PHP 5.3 auf PHP 5.4 zu aktualisieren zusammenhängt, da hier sehr viele Dienste aktualisiert wurden. Endresultat war jedoch, dass ich wieder auf PHP5.3 zurück ging, da ich es nicht hinbekam.

An was kann das liegen bzw. welchen Prozess bzw. welche Config sollte ich als nächstes in Angriff nehmen.

LG
 
Morgen,

ja und zwar:
51 bei lockedpages
5181403 bei tcpsndbuf
1 bei numothersock
und
941736 bei numfile

Dabei steht aber lediglich numfile über dem Limit 17600?

LG
 
Danke für den Hinweis. Die beiden Quellen hatte ich auch vor wenigen Minuten gegoogelt.

Hätte ja nie gedacht, dass meine paar Joomla Seiten (ca. 20 Joomlas, 2 Piwiks, 1 eGroupWare und 1 vTiger) den Advanced Server bei HE derart auslasten? Gut die Piwik Datenbanken sind schon über 500MB groß.
Dabei sind die Besucher der besten Seite am Tag < 500.

PHP läuft als CGI bei allen.
Kann man denn eine grobe Richtlinie sagen z.b. für 10 Joomlas PHP als CGI a 200 Besucher/Tag sind 2GB RAM o.ä. notwendig?

Wie hängt das nun aber mit den Logfiles zusammen? Sollte ich die Failcounts zurücksetzen und würde ich dann "erstmal" wieder die korrekte Funktion erwarten können?
Ein Serverupgrade steht sowiso an.

LG
 
Also ein Rücksetzen der Counter nutzt nichts, die zeigen Dir ja nur den Missstand an.
Aktuell sind auf deinem System zuviele Files geöffnet, wie schon gesagt, das kannst Du evtl ändern, indem Du den Server neustartest. Ob das aber eine langfristig gute Maßnahme ist musst Du selbst rausfinden, einfach mal die user_beancounters überwachen. Es kann z.b. sein, dass durch deine Updatemaßnahme das Fass zum überlaufen gebracht worden ist.

Richtwerte kann ich Dir leider keine nennen. Mir kam nur dein Fehlerbild sehr bekannt vor. Gerade bei vServern treten da schon mal schnell sehr bizarre Effekte auf, z.B. beim Überlaufen von tcpsndbuf ist der Server mal nicht mehr via Internet erreichbar, bei numproc killt er prozesse, auch mal gern den sshd. ;-)

Richtig doof finde ich, dass man vor Kauf eines vServers von den ISP selten nur erfährt wie die Werte gesetzt sind.
Zu hoch ist auch ungünstig, bei 1blu hatte ich mal nen vServer da waren alle die Werte auf maximum, sehr zur Freude von Powerusern auf Lasten der Nachbarn...

Ist eben die erkaufte Problematik bei virtualisierten Kisten.
 
Du würdest mir einen dedizierten Server empfehlen?
Nun woher weiß ich denn, dass hier nicht doch wieder "nur" virtualisiert wird.

Was mache ich nun aber erstmal mit meinen Logfiles? Die Reboots alle Wochen wennd er Speicher knapp wird könnte ich absolut verkraften. "fürs erste".
Aber trotz mehrerer Reboots seit Samstag werden mir nach wie vor die Logs nicht geschrieben obwohl der Server vom Limit entfernt ist.
Berechtigungen passen soweit, die auth.log habe ich z.b. komplett entfernt, die müsste ja spätestens nach Neustart neu angelegt werden oder?
Die Files stehen nach wie vor alle auf Anfang November.

LG
 
Das war keine absolute Empfehlung für dedizierte Rechner, ich bin nach wie vor Freund von virtualisierten Kisten.

Wenn Dir ein Anbieter ne dedizierte Kiste verkauft muss es auch eine sein!

Warum das bei Dir sonst nicht weiter funktioniert, trotz Neustart ist schwer abzuschätzen. Evtl hat ja noch jemand ne gute Idee.
 
KvM wäre auch noch eine Lösung, da gibt es diese Stellschrauben nicht und eigene Kernel sind möglich.
Da bleiben halt die anderen, üblichen Flaschenhälse, die auftreten KÖNNEN: Disk I/O, etc...
 
Vor wenigen Tagen hatte ich ja z.b. die auth.log entfernt, welche mir normalerweise doch dann neu angelegt werden sollte oder?

Nach wie vor ist keine auth.log vorhanden und auch alle anderen Logfiles wurden wie schon beschrieben nicht weiter geschrieben.

Der Server fährt momentan stabil mit 2,5GB Ram und fällt auch anderweitig nicht mehr negativ auf. Größte Auslastung verursachten meine Piwik Installationen, welche auch in den Browsern ständig offen waren.

LG
 
Öhm... nun mal langsam.
Nur weil du irgendwann mal Ressourcenprobleme hattest (failcount ist kein aktueller Wert), wird hier gleich mit Kanonen auf Spatzen geschossen.
Logdateien einfach löschen ist übrigens unclever.

Und nun zu deinem eigentlichen Problem. Es werden gar keine oder nur bestimmte Logdateien nicht mehr geschrieben? Können andere Dateien noch geschrieben werden? Läuft dein syslog-Daemon überhaupt?

Poste mal bitte die Ausgaben der folgenden Befehle:

Code: 
$(find /etc/init.d/ -name '*log*') status
df -h
df -i
mount
touch /var/log/test.log
 
Hallo,

sollte denn die auth.log nicht neu angelegt werden? Hier wollte ich eventuelle Berechtigungsprobleme sehen, denn bei "ls -l" erschien alles i.O.

Hier die Infos:
Code: 
# $(find /etc/init.d/ -name '*log*') status
kein Resultat

# find /etc/init.d/ -name '*log*'
/etc/init.d/stop-bootlogd
/etc/init.d/stop-bootlogd-single
/etc/init.d/bootlogs
/etc/init.d/klogd
/etc/init.d/rmnologin
/etc/init.d/sysklogd
/etc/init.d/bootlogd

# df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/vzfs       125G     17G  109G   13% /

# df -i
Dateisystem     Inodes IBenutzt   IFrei IUse% Eingehängt auf
/dev/vzfs      6000000   408696 5591304    7% /

# mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)

#  touch /var/log/test.log
# cd /var/log
# ls -l
...
-rw-r--r-- 1 root        root           0 Nov 26 16:30 test.log
...

Geschrieben werden seit Anfang November nicht mehr:
  • auth.log
  • daemon.log
  • debug
  • fontconfig.log
  • mail.err
  • mail.info
  • mail.log
  • mail.warn
  • messages
  • mysql.err
  • razor-agent.log
  • syslog
  • user.log
  • xconsole.log

Zumindest haben die besagtes Datum.

LG
5ky
 
Okay, woher siehst du dass der Prozess nicht läuft?

Ein:
/etc/init.d/sysklogd restart

bringt leider nichts.

Die Datei /etc/syslog.conf ist identisch den Servern welche in Ordnung sind?

Ein "pgrep sysklogd" bestätigt aber, dass der Dienst nicht läuft...
 
5ky said:
Okay, woher siehst du dass der Prozess nicht läuft?
Click to expand...

Daran:

5ky said:
Code: 
# $(find /etc/init.d/ -name '*log*') status
kein Resultat
Click to expand...

Dann solltest du dich vielleicht mal auf Suche begeben, warum er nicht startet. ;)
Vielleicht mal von Hand und nicht übers Init-Script starten. Dann sieht man auch mal paar Fehlermeldungen. Oder die Kanone für den kleinen Spatz rausholen und strace dran hängen. ;)

Ein vollständiger Auszug (und nicht nur die failcnts) der UBCs wäre auch ganz praktisch.
 
Wenn der Prozess laufen würde, hätte der Befehl "$(find /etc/init.d/ -name '*log*') status" irgendwas in der Art von "sysklogd (PID 39854) is running ..." ausgegeben.

Und nun darfst das Init-Skript debuggen :)

Edit: Da Firewire2002 ja wieder die Kanonen auspackt, könntest du das Init-Skript natürlich auch in einer Debugging-Bash (bash -x) ausführen :)
 
Code: 
# apt-get install sysklogd
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  libhtml-template-perl
Verwenden Sie »apt-get autoremove«, um es zu entfernen.
Die folgenden zusätzlichen Pakete werden installiert:
  klogd
Die folgenden Pakete werden ENTFERNT:
  apache2 apache2-mpm-worker apache2-suexec apache2.2-common chkrootkit dmsetup e2fsprogs ifupdown initramfs-tools
  initscripts libapache2-mod-fcgid libapache2-svn libdevmapper1.02.1 mysql-server mysql-server-5.5 openssh-server procps
  ssh sysvinit udev util-linux
Die folgenden NEUEN Pakete werden installiert:
  klogd sysklogd
WARNUNG: Die folgenden essentiellen Pakete werden entfernt.
Dies sollte NICHT geschehen, außer Sie wissen genau, was Sie tun!
  e2fsprogs util-linux (wegen e2fsprogs) sysvinit initscripts (wegen sysvinit)
0 aktualisiert, 2 neu installiert, 21 zu entfernen und 0 nicht aktualisiert.
Es müssen 109 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 43,0 MB Plattenplatz freigegeben.
Sie sind im Begriff, etwas potentiell Schädliches zu tun.
Zum Fortfahren geben Sie bitte »Ja, tue was ich sage!« ein.

hilfe...

Das erklärt warum der Dienst nicht startet. Dass mir aber derartig wichtige Prozesse deinstalliert würden???

Jetzt werd ich gleich ausgelacht mit dem Kommentar: what the hell you´ve done...
 
Last edited by a moderator:
Stimmt. RSysLog entfernt lediglich klogd und sysklogd.

Sollte wohl laut Google mit den bestehenden Config-Files zurecht kommen.

Wüsstet ihr noch Sachen, die ich bevor ich auf "J" drücke evtl. beachten sollte?
 
Hey,
wollte gerade RSysLog nun endgültig installieren, etz bringt er heute gleiches wie bei sysklogd, dass er Apache2, mysql etc entfernt...
LG
 
You must log in or register to reply here.
Back
Top