Beiträge von Ebbecindy

Gemacht. Ergebnis:

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.

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!

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?

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!

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:

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#

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:

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

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

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??

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:

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...

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

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!

Hallo,
jetzt muss ich doch um Entschuldigung bitten, dass ich Euch hier alle belästigt habe. Der Fehler ist gefunden und beseitigt.

Was war's?
Ein so lächerlicher und naheliegender Fehler, dass man ihn übersehen musste: Beim Sat-Kabel hat sich ein Stecker gelockert und einen Kurzschluss verursacht (wenn's beim Stecker am Gerät gewesen wär, dann hätt' ichs ja noch kapiert, aber es war der Stecker im Dach!). Demnach lag ich mit meiner Diagnose garnet so verkehrt:

Zitat

Kein Bild, kein Ton, keine EPG-Daten. Scheint so, dass die Karte nichts empfängt. Hat sie aber schonmal, also nehme ich an, dass da irgendwas bei der Initialisierung schief läuft, nur was?

Nur die Folgerung daraus war in die falsche Richtung. Glücklicherweise hat die Karte die Tortur ohne Schaden überstanden und läuft nach wie vor.

Wie hab' ich's gefunden?
Zu Testzwecken hatte ich mir auf einer kleinen, alten IDE-Platte WindoofsXP aufgespielt und die von TT mitgelieferten Programme installiert. Also SATA-Platte mit dem Mahlzeit-VDR abgeklemmt, IDE-Platte angeschlossen. Nach der Bill-Gates-Gedenk-Viertelstunde musste ich feststellen, dass auch die vormals funktionierende Installation spann, das TT-Programm stürzte ab. Also kein Software-Fehler, sondern einer in der Hardware. Mit dem SAT-Tester im Kabel dann festgestellt, dass beim Anschluss der Zuleitung das Licht ausgeht. Dann war's klar.

Schon dumm, dass man bei solchen Geschichten immer erstmal im Nebel (sprich: in der Software und ihrer Konfiguration) stochert, bevor man die offensichlichen Sachen überprüft.

Euch Allen ein Gutes Neues Jahr und dass euere Wünsche so in Erfüllung gehen mögen, wie's am Besten für Euch ist!

Hallo,

habe während der Feiertage mein System zusammengebaut und auf der Suche nach einem geeigneten Programmpaket bin ich über das -ISO gestolpert. Also installiert und nach einigem Hin und Her ging's dann endlich.

Anmerkung: Die Kombination DVB-s TT 2.3 und SATA-Platte hat es schon in sich. Wie gut dass der neue Kernel beim ISO schon mit drin ist, der beides kann.
Allerdings: Installation über ein Linux-basiertes System schlug regelmäßig fehl, wohl, weil Grub dann sein Ziel nicht mehr fand. Ebenso erging's mir beim "Drüberbügeln" von der CD. Danach kam erstmal das System nicht mehr hoch. Das wär' schon schön, wenn man dann die CD direkt als "Reparaturdisk" nutzen könnte.

Nach ungefähr zwei Tagen Arbeit für den Einbau des Displays und der Suche nach den Stellen, wo man's aktivieren kann, kam auch hier die Erleuchtung in Form des erwünschten Bildchens.

Hier ist erstmal ein dickes DANKESCHÖN angebracht für diejenigen, die sich die Entwicklung und den Support eines solchen Systems auf die Fahnen geschrieben haben, insbesondere die Verwaltung der Plugins und das Update-System find ich Spitze!

Inzwischen hatte ich wohl das System soweit verwurstelt gehabt, dass ich nicht mehr klar kam.
Also Holzhammermethode: Platte putzen und nach Bereinigen der letzten Reste von Grub neu installieren. Jetzt hab' ich zwar die Fehlermeldung "Respawning to fast..." weg, das Display ist wieder eingerichtet und auch die Sache mit dem falschen Eintrag für den Proxy ist ausgestanden, d.h. das Update läuft.
Aber die Anzeige des TV-Bildes auf dem angeschlossenen Monitor und im vorher vollständig funktionierenden VDRadmin krieg' ich nicht mehr gebacken. Zwar wird das Programm im Display und im Monitor eingeblendet, aber es kommt kein empfangenes Signal. Kein Bild, kein Ton, keine EPG-Daten. Scheint so, dass die Karte nichts empfängt. Hat sie aber schonmal, also nehme ich an, dass da irgendwas bei der Initialisierung schief läuft, nur was??? Dazu hab' ich noch nichts gefunden. (Auch nicht nach etwa 10 Stunden heftigen Lesens und Suchens im VDR-Portal. Da hab' ich zwar einiges dabei gelernt, aber der eine wichtige Punkt war nicht dabei.) Wahrscheinlich bin ich auch nur blind für den richtigen Ansatz und hab ihn schon -zig mal überlesen.

Nun hoff' ich auf einen Tip von den "Erleuchteten", die auf Anhieb wissen, wie man überprüfen kann, was alles läuft und aus den Hinweisen auch noch herauslesen können, wo's hängt. Bin zwar kein völliger Linux-DAU mehr, habe mich aber bisher noch nie mit einem so effektiv schlank gemachten und auf einen Zweck hin optimierten System beschäftigt gehabt.
(Für die des log-Lesens Kundigen ist auch noch eine Kopie vom logread angehängt).

Bin dankbar für jeden Hinweis, der die Kiste wieder zum Laufen bringt.

Danke!