Mahlzeit 4 und load >>1

Ebbecindy · 29. Juni 2009

Hallo,

ich kämpfe gerade mit folgendem Problem:
Zugriff auf linvdr über http (VDRAdmin) ist äusserst zäh; bis die ersten Elemente auftauchen, dauert es teilweise über 3 min!
Also über Putty 'reingeschaut:

Code

LinVDR:~# top
top - 22:18:37 up 27 min, 1 user, load average: 5.12, 6.50, 6.21
Tasks: 77 total, 5 running, 72 sleeping, 0 stopped, 0 zombie
Cpu(s): 10.6%us, 88.0%sy, 0.3%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st
Mem: 967692k total, 139616k used, 828076k free, 8644k buffers
Swap: 0k total, 0k used, 0k free, 65828k cached


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1596 daemon 20 0 15424 14m 304 R 33.5 1.5 7:39.10 atd
1587 root 20 0 2160 256 200 S 1.3 0.0 0:31.53 syslogd
15665 root 39 19 53636 20m 5700 R 0.3 2.2 0:06.55 vdr
27428 root 20 0 1944 996 780 R 0.3 0.1 0:00.03 top
1 root 20 0 2140 288 236 S 0.0 0.0 0:00.72 init
usw...

Alles anzeigen

und das kurz nach einem Neustart!

Anscheinend kloppt sich da ein Prozess um die Abarbeitung: atd!

In /var/spool/cron/atjobs stehen 27 urig alte Jobs alle vom 25.August drin.

Fragen:
Wie krieg ich die Jobs los?
sie werden wohl wegen des in logread angezeigten Fehlers

Code

Jun 29 22:29:30 LinVDR cron.err atd[24357]: Job 13 (a0000d01362e61) - userid 0 does not match file uid 1
Jun 29 22:29:30 LinVDR cron.err atd[24358]: Job 12 (a0000c01362e61) - userid 0 does not match file uid 1
Jun 29 22:29:30 LinVDR cron.err atd[24359]: Job 11 (a0000b01362e61) - userid 0 does not match file uid 1
Jun 29 22:29:30 LinVDR cron.err atd[24360]: Job 10 (a0000a01362e61) - userid 0 does not match file uid 1
Jun 29 22:29:30 LinVDR cron.err atd[24363]: Job 8 (a0000801362e61) - userid 0 does not match file uid 1

nicht abgearbeitet und blockieren damit das ganze System.
Wie krieg' ich die Leichen aus dem Keller?

Danke für jede Hilfe!

tomas · 30. Juni 2009

Zitat

Original von Ebbecindy

Wie krieg' ich die Leichen aus dem Keller?

Hallo,

meine Tochter hatte mit ihrem Mahlzeitrechner vor ein paar Monaten das gleiche Problem, waren glaub ich alte tvmovie-jobs. Ich hab sie dann das hier

Code

for i in `atq|cut -f1`; do atrm $i; done

absetzen lassen, dann war Ruhe.

Gruß, tomas

Ebbecindy · 30. Juni 2009

Danke, Thomas!
Werd' ich demnächst probieren.
Nur befürchte ich, dass das grundlegende Problem dabei nicht gelöst wird.
Warum legt er Files mit UID 1 an und erwartet dann aber bei der Abarbeitung UID 0 und produziert möglicherweise wieder neue "Leichen" ?
Oder war das ein vorübergehendes Problem und wird in Zukunft nicht mehr auftreten??

tomas · 30. Juni 2009

Hallo,

Zitat

Original von Ebbecindy

Warum legt er Files mit UID 1 an und erwartet dann aber bei der Abarbeitung UID 0

Keine Ahnung.

Zitat

Oder war das ein vorübergehendes Problem und wird in Zukunft nicht mehr auftreten??

Wenn die jobs schon fast ein Jahr alt sind, sollte man davon ausgehen können.

Du kannst dir ja aber die jobs mal ansehen. Ich denke die liegen bei Mahlzeit 4 auch in /ramdisk/cron/atjobs.

EDIT: hast ja oben geschrieben, dass die in /var/spool/cron/atjobs liegen, wobei /var/spool/cron auf /ramdisk/cron verlinkt ist.

Einfach mit einem Editor öffnen und schauen, was da jeweils abgearbeitet werden sollte (steht ganz am Ende).

Gruß, tomas

Ebbecindy · 30. Juni 2009

Hallo,
danke, thomas für die Antworten.
Ich hab' mir zunächst 'mal die Dateien angeschaut. Der Inhalt von so einer Datei - übrigens alle identisch bis auf den Namen - ist folgender:

Code

LinVDR:/ramdisk/cron/atjobs# cat < a0001701362e61 


#!/bin/sh 
# atrun uid=0 gid=0 
# mail     root 0 
umask 22 
SSH_CLIENT=192.168.1.138\ 4035\ 22; export SSH_CLIENT 
SSH_TTY=/dev/ttyp0; export SSH_TTY 
LC_ALL=de_DE; export LC_ALL 
USER=root; export USER 
MAIL=/var/mail/root; export MAIL 
PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin:/sbin:/lib/lvm-200; export PATH 
PWD=/etc/vdr; export PWD 
HISTCONTROL=ignorespace; export HISTCONTROL 
SHLVL=3; export SHLVL 
HOME=/root; export HOME 
LOGNAME=root; export LOGNAME 
MC_CONTROL_FILE=/tmp/mc.20253.control; export MC_CONTROL_FILE cd /etc/vdr || {
          echo 'Execution directory inaccessible' >&2
          exit 1 
}  


LinVDR:/ramdisk/cron/atjobs#

Alles anzeigen

und das scheint mir irgend eine Initialisierung von Systemvariablen zu sein.
Da alle gleich sind, ist die Frage: Wie loswerden?
Einfach in /ramdisk/cron/atjobs löschen? Läuft dann das System vielleicht Amok, weil irgend welche Indizes nicht mehr passen?
Komischerweise waren sie nach dem reboot auch vorhanden. Baut "Mahlzeit" nach dem Neustart die Ramdisk nicht neu auf? Müssten die Einträge dann nicht gelöscht sein? Hilft vielleicht ein richtiger Kaltstart mit Netzteil aus und warten?

Hmmm, ich weiss, Fragen über Fragen, aber ich möchte ja versuchen, das System ein bisschen besser zu verstehen und nicht auf dem Stand eines nur-Installierers und DAUs stehen zu bleiben.

Danke für die Geduld!

Edit: Ich hab' 'mal deinen ersten tip probiert. Siehe da, die Jobs waren weg und top sieht jetzt auch wieder "normal" aus:

Code

LinVDR:/ramdisk/cron/atjobs# top 
top - 20:55:12 up 23:03,  1 user,  load average: 0.30, 1.36, 1.84 
Tasks:  73 total,   1 running,  72 sleeping,   0 stopped,   0 zombie 
Cpu(s):  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st 
Mem:    967692k total,   289296k used,   678396k free,    25412k buffers Swap:        0k total,        0k used,        0k free,    66524k cached    
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  
9326 root      20   0  1940  992  780 R  0.3  0.1   0:00.11 top     
1 root      20   0  2140  288  236 S  0.0  0.0   0:00.72 init     
2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd     
3 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0     
4 root      15  -5     0    0    0 S  0.0  0.0   0:00.01 ksoftirqd/0     
5 root      15  -5     0    0    0 S  0.0  0.0   0:01.13 events/0     
6 root      15  -5     0    0    0 S  0.0  0.0   0:00.02 khelper

Alles anzeigen

Und VDRadmin läuft auch wieder wie gewohnt (zwar etwas stockend, aber das ist wohl normal)
Danke!

tomas · 30. Juni 2009

Hallo,

der Inhalt der Datei ist eigentlich *normal*, nur ist mir nicht klar was der job überhaupt tun soll.

Ein atjob mit dem Auftrag "hallo Ebbecindy" auszugeben sieht z.B. so aus:

Bash

#!/bin/sh
# atrun uid=0 gid=0
# mail     root 0
umask 22
SSH_CLIENT=192.168.2.11\ 43967\ 22; export SSH_CLIENT
SSH_TTY=/dev/ttyp0; export SSH_TTY
USER=root; export USER
MAIL=/var/mail/root; export MAIL
PATH=/bin:/usr/bin:/usr/sbin:/usr/local/bin:/sbin; export PATH
PWD=/var/spool/cron/atjobs; export PWD
PS1=\\h:\\w#\ ; export PS1
SHLVL=1; export SHLVL
HOME=/root; export HOME
LOGNAME=root; export LOGNAME
OLDPWD=/var/spool/cron; export OLDPWD
cd /ramdisk/cron/atjobs || {
         echo 'Execution directory inaccessible' >&2
         exit 1
}
echo "hallo Ebbecindy"

Alles anzeigen

In der letzten Zeile steht der auszuführende Befehl, vorher werden nur Environment-Variable definiert.

Bei dir fehlt der auszuführende Befehl, keine Ahnung warum.

EDIT: kann es sein, dass du an diesem 25.August letztes Jahr über ssh mit *at* rumgespielt hast?

Zitat

SSH_CLIENT=192.168.1.138\ 4035\ 22; export SSH_CLIENT

kann nur in der Datei enthalten sein, wenn der job über ssh angelegt wurde!

Zitat

Einfach in /ramdisk/cron/atjobs löschen? Läuft dann das System vielleicht Amok, weil irgend welche Indizes nicht mehr passen?

atjobs löscht man nicht von Hand sondern mit dem Befehl atrm <jobnummer>. Die Jobnummer bekommt man über den Befehl atq. atq listet alle jobs nach folgendem Muster auf *1928 2009-06-30 23:00 a root*. In der ersten Spalte steht die Jobnummer dann Datum, Uhrzeit und Autraggeber des jobs.

Code

for i in `atq|cut -f1`; do atrm $i; done

gibt alle vorhandenen jobs aus, extrahiert die erste Spalte mit der Jobnummer und übergibt sie an atrm. Natürlich könnte man das auch einzeln von Hand machen, aber wenn man sowieso alle jobs los werden will, gehts halt wesentlich schneller.

Gruß, tomas

Ebbecindy · 1. Juli 2009

Hallo thomas,
Danke für die schnelle und erschöpfende Auskunft.
Wieder 'was gelernt!

Zitat

Original von tomas

EDIT: kann es sein, dass du an diesem 25.August letztes Jahr über ssh mit *at* rumgespielt hast?

kann nur in der Datei enthalten sein, wenn der job über ssh angelegt wurde!
.....
Gruß, tomas

Alles anzeigen

Hmm, ich geh' normalerweise schon für administrative Geschichten per ssh auf den Rechner, aber der Befehl at ist mir erst jetzt bekannt geworden und wie man ihn einsetzen könnte, muss ich mir auch erst noch anlesen.

Woher die Jobs kamen wird sich jetzt wohl nicht mehr aufklären lassen, komisch nur, dass sie - obwohl leer - nicht "abgearbeitet" werden konnten, weil die uid nicht passte.

Zumindest läuft mein System jetzt wieder zufriedenstellend und der VDRAdmin reagiert auch wieder.

Deshalb nochmals ein großes TNX!

Ebbecindy · 12. Juli 2009

Hallo,
wie ich schon befürchtet habe, ist es mit dem Löschen der cronjobs nicht getan;
nicht einmal zwei Wochen nach der "Aufräumaktion" stehen schon wieder 30 solcher (leerer) Cronjobs im Directory ramdisk/cron/atjobs, alle mit Datum 25.Aug 2008.
Logread zeigt mir wieder denselben Fehler wie bereits gepostet.
Load ist etwa 5 und die CPU zu 35% ausgelastet. Das kann's doch wohl nicht sein!
Klar kann ich sie wieder 'rauslöschen, aber.. die Liste scheint sich magisch immer wieder zu füllen. Irgendwie sollte man doch die Ursache 'rauskriegen und beseitigen können, oder?

tomas · 13. Juli 2009

Irgendwie scheint sich dein VDR ohne mindestens 20 at-Leichen nicht wohl zu fühlen.

Einen kleinen Gothic-VDR hat ja auch nicht jeder;)

aber mal im Ernst:

einen at-job in die *Vergangenheit* zu legen ist eigentlich gar nicht möglich!

Code

~$ at 25 AUG 2008
at: refusing to create job destined in the past

Ich würde die neuen Leichen erst mal wieder löschen um zu sehen, ob die jobs auf *einmal* wieder auftauchen oder sich *nach und nach* wieder vermehren.

Der Rechner läuft ja schon mit der richtigen Zeit, oder? ........sonst würde ja wohl auch EPG und Timer bzw. wakeup nicht funktionieren..... hmmm vielleicht doch zur Sicherheit mal *date* ausführen...

Gruß, tomas

Ebbecindy · 13. Juli 2009

Zitat
Original von tomas
Code
~$ at 25 AUG 2008
at: refusing to create job destined in the past
Ich würde die neuen Leichen erst mal wieder löschen um zu sehen, ob die jobs auf *einmal* wieder auftauchen oder sich *nach und nach* wieder vermehren.

Heute nachgeschaut: schon wieder zwei "Leichen" mit Datum 25.08.08
Gestern einen Timer gesetzt und ab 20:15 aufzeichnen lassen. Vielleicht ist das ja die Ursache?

Zitat

Der Rechner läuft ja schon mit der richtigen Zeit, oder? ........sonst würde ja wohl auch EPG und Timer bzw. wakeup nicht funktionieren..... hmmm vielleicht doch zur Sicherheit mal *date* ausführen...

Gemacht: Zeit stimmt auf die Sekunde genau!
Also ich kapier' das nicht.

Danke für die gemeinsame "Fährtensuche", thomas!

tomas · 13. Juli 2009

mit einem

Code

ls -al /ramdisk/cron/atjobs

könntest du mal nachschauen, wann die Jobs angelegt wurden.

Dann noch zusätzlich das syslog einschalten, dann könnte man in Zukunft eingrenzen, was der Rechner zu dem Zeitpunkt gerade gemacht hat, zu dem die jobs angelegt wurden.

Ebbecindy · 13. Juli 2009

Gemacht. Ergebnis:

Code

LinVDR:~# ls -al /ramdisk/cron/atjobs
drwxr-xr-x    2 daemon   daemon        100 Jul 13 18:39 .
drwxr-xr-x    5 root     root          120 Jul 13 18:35 ..
-rw-r--r--    1 daemon   daemon          6 Jul 12 12:27 .SEQ
-rwx------    2 daemon   daemon        587 Aug 25  2008 =0001201362e61
-rwx------    2 daemon   daemon        587 Aug 25  2008 a0001201362e61
LinVDR:~#

Beide wieder - wie oben beschrieben - bis auf die Variablen-Definition leer.

tomas · 13. Juli 2009

aha da kommen wir der Sache schon näher. Entscheidend ist die Zeit der .SEQ, die anzeigt wann der letzte job angelegt wurde.

Zitat

-rw-r--r-- 1 daemon daemon 6 Jul 12 12:27 .SEQ

also müsste der letzte job am 6 Jul 12 12:27 angelegt worden sein. Wie gesagt syslog einschalten und dann bei der nächsten Veränderung der .SEQ schauen, was der Rechner da getrieben hat

Mahlzeit 4 und load >>1

Jetzt mitmachen!

Teilen