• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[cancel] trap-Bug ODER IrrtumVonMir_im_ShellScript

Jiep1963

Jiep1963

Hallo Liste,

wegen meinem schlechten Englisch bin ich von deutschen Texten abhängig. :eek:ps:
Aber dort konnte ich nichts zu meinem Problem finden (googel, eigene Bücher, Buchladen).

Aufgrund getesteter Situation bin ich mir nicht sicher ob es ein Bug ist, :???:
oder einfach nur ein Irrtum meinerseits. :irre:

Wer könnte mir also dabei helfen der Sache auf dem Grund zu gehen? :schockiert:

Gruß Achim, alias Jiep

System::eek:penSUSE 10.2 :D
------------

Situation:
Ein und ausgehende Dateien (Internet) sollen nach Standart abgearbeitet
werden.

Aufgabe:
* Es gibt mehrere Scripte von start.ksh und main.ksh. Diese haben unterschiedliche verschiedene Aufgaben und Abläufe für darunter liegende Scripte definiert.
* Main-Scripte regeln den logischen Ablauf, aber nicht die Detailsteuerung.
* Darunter liegende Scripte (zahlenmäßig viele) sollen wiederverwendbar sein, so das neu gestaltete main.scripte diese sofort nutzen koennen und regeln die Detail-Steuerung. Protokolle schreiben log err, mail, ftp, ssh, usw.
* Nach einem Rebot soll die Arbeit dort wieder aufgenommen werden, wo sie vor dem Reboot unterbrochen wurde.
* ...

Für den letzten Punkt "Arbeitsaufnahme" habe ich zwar eine (einiger maßen) logische korrekte Lösung gefunden ABER das trap-Kommando arbeitet nicht richtig!

Lade ich das trap-script dierekt in das main-Script, wird niemals das trap-Kommando nach meinen Vorstellunge ausgeführt.

Lade ich das trap-script innerhalb einer der while-Schleifen im Kommando-Script, wird es wie nach den Zufallsprinzip ignoriert oder korrekt ausgeführt »» kill -SIG PID »»

1.) Shell meldet z.B. nur "beendet"

ODER

2.) trap schreibt in Log+Error-Files UND erstellt die Datei mit Namen
Datei_SIG_Script_Stop
2.1) commando_ausfuehren.ksh findet Datei_SIG_Script_Stop und beendet sich
kontrolliert


---------------- vereinfachte Script-Darstellung -----------

con startet start.ksh

start.ksh
#
Datei_SIG_Script_Stop vorhanden?
ja: neu dann exit
ja: alt dann loeschen
#
neue Datei.tar.gz.pgp....
ja: starte main.ksh mit NeueDateNamen
nein: exit
#
### EOFstart.ksh



main.ksh ARGV[1]
#
. trap.ksh
. error_handling.ksh
. schreibe_log.ksh
. command_ausfuehren.ksh
. embeddet_functions.ksh
#
Kommandodatei.dat vorhanden?
ja: starte commando_ausfuehren.ksh Kommandodatei.dat
#
nein: echo "gpg NeueDateiNamen" > Kommandodatei.dat
echo "gz NeueDateiNamen" >> Kommandodatei.dat
echo "tar NeueDateiNamen" >> Kommandodatei.dat
echo "mv .... usw.usw.usw" >> Kommandodatei.dat
#
starte commando_ausfuehren.ksh Kommandodatei.dat
### EOFmain.ksh



trap.ksh
#
case UNUX.system
. Linux_SIG.dat
. HPUX_SIG.dat
. SUN_SIG.dat
. AIX_SIG.dat
esac
#
SIGNAL?
ja: schreibe bei SIG in logfine.txt
ja: touch Datei_SIG_Script_Stop
###EOFtrap.ksh



commando_ausfuehren.ksh $1
#
function_protokoll
#
(schreibe logfiles / Errorfiles / Mail an Admin ... je nach Situation
#
#
function_kommaodausfuehrung
#
kommandoaufruf parameter [parameter [parametert]]
#
#
while [ Kommandodatei.dat]
#
read <Kommandodatei.dat
while [ commandozeile]
#
Zeile[@] = commandozeile]
#
done
#
while[ Zeile ]
#
aktuelleskommado = Zeile[ n ]
cp -f Kommandodatei.dat Kommandodatei.sicher.$$
rm Kommandodatei.dat
#
while [ Zeile + 1 ]
Zeile[ n + 1 ] >> Kommandodatei.dat
Zeile++
done
#
function_kommaodausfuehrung aktuelleskommado
rm Kommandodatei.sicher.$$
#
Datei_SIG_Script_Stop vorhanden?
ja: exit
#
done #while_Zeile
#
done #while_Kommandodatei
#
### EOFcommando_ausfuehren.ksh
-----------------------------------------------------
 
A

Anonymous

Gast
Damit kann dir hier wohl keiner recht viel weiter helfen, es wird mindestens benötigt, das genaue Script oder die Abschnitte des Scriptes das nicht, oder sporatisch nicht funktioniert sowie die genauen Aufruf desselben, weiterhin die genauen Umgebungsbedingungen beim Aufruf, funktioniert es in allen BS nicht oder nur in einem nicht, bei Verdacht auf Problemen mit einzelner Shells auch gleich noch welche Shell (Versionsgenau) funktioniert in welchem BS nicht.

robi
 
OP
Jiep1963

Jiep1963

Hallo robi,

danke für Deine Antwort!

Ich habe gehofft, das über meine Kurzdarstellung jemand das Problem irgendwie aus eigener Erfahrung wiedererkennt. Ansonsten bezweifle ich, dass mir jemand bei der Lösung helfen kann.

Die Scripte sollen dynamisch in der Wiederverwertung aber leicht wartbar sein. Daraus folgt, das es viele kleine geworden sind, die nach bedarf aufgerufen werden...
Um diese Menge an Scripte zu verwalten, beauftrag das Main-Script über eine Orderdatei ein dazwischenliegendes Script, das diese Order liest und darüber die darunter liegenden Scripte aufruft und verwaltet, Log-Files schreibt, aber auch trap händelt. Und genau am trap-handling scheitert es. Ich weis nicht genau woran es liegt das trap wie nach Zufall reagiert. Vielleicht weil das Script über . eingelesen wurde - vielleicht weil while nicht richtig programmiert ist ....
IdR aber macht der Programmierer (ich) den Fehler! Ich habe keine Ahnung wo die Antwort auf mein Problem liegt.

Wäre schön wenn es jemanden gibt der mit mir die Lösung sucht und findet - denn auch ich bin gerne bereit Wissen zu teilen!

-------------

robi schrieb:
Damit kann dir hier wohl keiner recht viel weiter helfen, es wird mindestens benötigt, das genaue Script oder die Abschnitte des Scriptes das nicht, oder sporatisch nicht funktioniert sowie die genauen Aufruf desselben, weiterhin die genauen Umgebungsbedingungen beim Aufruf, funktioniert es in allen BS nicht oder nur in einem nicht, bei Verdacht auf Problemen mit einzelner Shells auch gleich noch welche Shell (Versionsgenau) funktioniert in welchem BS nicht.

robi
Zum Vergrößern anklicken....
 
OP
Jiep1963

Jiep1963

Menschlich: Das es in Foren immer Besserwisser geben muss, die zum Hobby haben andere zu beleidigen VERSUCHEN. Da musst Du mir schon vorher bewiesen haben, das Du ohne Sponsoring Dein Leben meistern kannst bevor das bei mir funktioniert!
Die richtigen Umgangsformen im Business. Wir geben Hilfestellung: http://www.jobware.de/ra/fue/bk/1.html#

Fachlich zu "EINEM Script": Viel Erfahrung mit Scripten die Du beim Kunden entknoten musst, kannst Du nicht haben!

----------------------------------------------------

abgdf schrieb:
... schon Dein Deutsch finde ich ziemlich krass:
googel
auf dem Grund zu gehen
Standart
Zum Vergrößern anklicken....
http://www.deutschesprache-schweresprache.de/standart/

Auch das:
Darunter liegende Scripte (zahlenmäßig viele)
Zum Vergrößern anklicken....
ist wahrscheinlich nicht nötig.

Versuche, Deine Aufgaben (ich habe keine Ahnung, welche) in EINEM Skript zu erledigen.

Gruß
Zum Vergrößern anklicken....
 
OP
Jiep1963

Jiep1963

Hi Tux, erstmal Danke für die Anregungen!

Es sind viele kleine Scripte die je nach Aufgabe auf verschiedene Verzeichnisse verteilt sind. Ich kann gerne das Shell.tar.gz (95 KB) als Mail zusenden ...um dann mit jemanden oder einer Gruppe darüber zu diskutieren ("der" openSource-Gedanke).

DER HINTERGRUND ist, das UNIX-Admins (HP, SUN, AIX) sich kompakte Scripte erstellen (ksh + awk + sed), die irgendwann sehr komplex werden. Und irgendwann hat niemand mehr Zeit diese Dinger zu pflegen oder zu entschlüsseln - ggf ist der Code mit den wachsenden Aufgaben überlastet und soll noch weitere Aufgaben übernehmen... Dann wird irgendein externer IT-ler beauftrag (ich z.B.) der das dann alles realisieren soll... Das ist ein Grauen!
Mit meinem Script will ich eine Art Konzeptschablone entwickeln. Und wen es auch immer interessiert - kann sich bei der Konzeptentwicklung beteiligen. (Wieder ein Baustein mehr M$ zu überholen!) Es gibt (relativ) viele Bücher über Shell-Programmierung. ABER KEINES WELCHES MAL KONZEPTE ANREGT.

Jiep

----------
}-Tux-{ schrieb:
Hmm warum postest du nicht einfach ein kleines Beispielscript, welches dein Problem beschreibt?

}-Tux-{
Zum Vergrößern anklicken....
 
A

Anonymous

Gast
Jiep1963 schrieb:
Es sind viele kleine Scripte die je nach Aufgabe auf verschiedene Verzeichnisse verteilt sind. Ich kann gerne das Shell.tar.gz (95 KB) als Mail zusenden ...um dann mit jemanden oder einer Gruppe darüber zu diskutieren ("der" openSource-Gedanke).
Zum Vergrößern anklicken....
Nichts gegen deine vielen kleinen Scripte, die will dir hier niemand wegnehmen, und mit Sicherheit will sich hier auch niemand länger und tiefer mit irgendwelchen globalen Problemen und dessen Lösungsmöglichkeiten befassen als unbedingt notwendig, haben meistens selbst genügend eigene Probleme mit denen wir uns sehr tiefgründig beschäftigen können, bevor uns langweilig wird. Wenn du Probleme mit einer Funktion oder einem Script hast, und du möchtest von hier Hilfe haben, dann brauchen wir hier das Konzentrat des Problemcodes, der genau diesen einen Problemfall aufzeigt, damit wir das Problem nachstellen können. Alles andere wird Kaffeesatzleserei. Wenn du ein Problem hast deinen Code auch nur abschnittweise hier öffentlich preiszugeben, dann bist du hier in diesem Forum falsch. Dann kannst du es mal dort versuchen http://www.freier-support.de . Hier wird ausschließlich mit offenen Karten und für alles zum Nachlesen gespielt.

robi
 
Wizzzard

Wizzzard

Ich versteh das Problem nicht.

trap wird meist genau einmal aufgerufen. Sinn des Befehls ist es, einen Signalhandler zu installieren. Mehr nicht.

Erhält jetzt der Prozess, der das Skript aufruft ein kill -<SIGNAL> <prozessid> so wird die mit trap registrierte shell-Funktion aufgerufen. Kindprozesse müssen natürlich ihren eigenen Signalhandler einrichten. Wartet das Skript auf einen Kindprozess, so kann es auf Signale erst wieder reagieren, wenn der Kindprozess beendet ist.

Das Einführen solch eines Gerüstes finde ich nicht sehr sinnig. Wenn man so etwas braucht, sollte man zu python der perl wechseln. Wenn ich einen ganzen Wust von Skript installieren muss, kann ich stattdessen mir besser gleich einen kompletten Interpreter installieren.
 
OP
Jiep1963

Jiep1963

Mein aktueller Teststand:

Bisher wurde das trap-Script nur im Main-Script über "." eingebettet - wie alle andere wichtigen Scripte auch; wobei dann im SIG-Fall das trap-Script überhaupt keine Reaktion zeigt. Beispiel einer nachgeladenen Kette der Scripte (Baum lässt sich hier nicht darstellen):

Main "." VaiablenExport "." TrapHandling "." LogFilePrint "." KommandoAbarbeiten "." IrgendeinKommando

Nun binde ich in ALLEN (wichtigen) Scripten über "." dieses trap-Script zusätzlich mit ein.

Nachwievor wird der kontrollierte Ausstieg mit exit (im KommandoAbarbeiten-Script) wie nach dem Zufallsprinzip vollzogen oder nicht vollzogen. ABER wenigstens erstellt das trap-Script nun immer die geforderte Datei "Script_STOP".

Merkwürdig + Auffällig: Vom Main bis zum allerletzten Script das über "." eingebunden wird, ist die PID die Gleiche. Aber es sieht wohl so aus, als ob trap die Scripte die (viel) später nachträglich über "."eingebunden werden nicht als gleichwertig / zugehörig behandelt; so als ob es Kinder wären für das es nicht zuständig ist.

----

> Wenn man so etwas braucht, sollte man zu python der perl wechseln <
ICH liebe Perl und mache sehr viel damit. Aber: Wenn ein Kunde jamanden sucht der in Shell (und schlimmstenfalls auch noch awk + sed) programiert, dann empfindet er Diskusionen darüber "nicht sehr sinnig!". Also versuche ich vor meinem nächsten Kundenprojekt ein Konzept und eine Schablone zu erstellen. Aber die sollte wenigsten funktionieren.

-----
Wizzzard schrieb:
Ich versteh das Problem nicht.

trap wird meist genau einmal aufgerufen. Sinn des Befehls ist es, einen Signalhandler zu installieren. Mehr nicht.

Erhält jetzt der Prozess, der das Skript aufruft ein kill -<SIGNAL> <prozessid> so wird die mit trap registrierte shell-Funktion aufgerufen. Kindprozesse müssen natürlich ihren eigenen Signalhandler einrichten. Wartet das Skript auf einen Kindprozess, so kann es auf Signale erst wieder reagieren, wenn der Kindprozess beendet ist.

Das Einführen solch eines Gerüstes finde ich nicht sehr sinnig. Wenn man so etwas braucht, sollte man zu python der perl wechseln. Wenn ich einen ganzen Wust von Skript installieren muss, kann ich stattdessen mir besser gleich einen kompletten Interpreter installieren.
Zum Vergrößern anklicken....
 
OP
Jiep1963

Jiep1963

Hallo robi,
ich habe KEINE Probleme etwas offen zu legen, sonst wäre ich nicht bereit eine Mail mit den vielen Scirpten zuzusenden.
Das Gebilde ist nur sehr komplex geworden und verteilt sich je nach Aufgabe auf verschiedene Dateien. Wenn ich das hier abbilde, werde ich berechtigt gefragt ob das nicht auch kürzer/übersichtlicher geht.
Genau wie Du bin ich der Meinung, das wir mehr davon haben wenn wir Wissen miteinander teilen und darauf aufbauend noch mehr daraus machen. Deine Meinung über mich kann somit nur ein Missverständnis sein.
---

robi schrieb:
Jiep1963 schrieb:
Es sind viele kleine Scripte die je nach Aufgabe auf verschiedene Verzeichnisse verteilt sind. Ich kann gerne das Shell.tar.gz (95 KB) als Mail zusenden ...um dann mit jemanden oder einer Gruppe darüber zu diskutieren ("der" openSource-Gedanke).
Zum Vergrößern anklicken....
Nichts gegen deine vielen kleinen Scripte, die will dir hier niemand wegnehmen, und mit Sicherheit will sich hier auch niemand länger und tiefer mit irgendwelchen globalen Problemen und dessen Lösungsmöglichkeiten befassen als unbedingt notwendig, haben meistens selbst genügend eigene Probleme mit denen wir uns sehr tiefgründig beschäftigen können, bevor uns langweilig wird. Wenn du Probleme mit einer Funktion oder einem Script hast, und du möchtest von hier Hilfe haben, dann brauchen wir hier das Konzentrat des Problemcodes, der genau diesen einen Problemfall aufzeigt, damit wir das Problem nachstellen können. Alles andere wird Kaffeesatzleserei. Wenn du ein Problem hast deinen Code auch nur abschnittweise hier öffentlich preiszugeben, dann bist du hier in diesem Forum falsch. Dann kannst du es mal dort versuchen http://www.freier-support.de . Hier wird ausschließlich mit offenen Karten und für alles zum Nachlesen gespielt.

robi
Zum Vergrößern anklicken....
 
A

abgdf

Ohne konkretes Problem geraten diese langen Beiträge gefährlich in den Bereich von

http://de.wikipedia.org/wiki/Troll_(Netzkultur)
 
OP
Jiep1963

Jiep1963

Schade, dass mir bisher bei meinem Problem keiner helfen konnte und ich hier aufgeben muss.

Sollte dennoch irgendwann einer auf das selbe Probleme stoßen und ich zwischenzeitlich (selbst) eine Antwort gefunden haben, kann er/sie mich gerne auch direkt ansprechen.

Ich möchte trotzdem all denjenigen danken, die sich bisher mit darum bemüht haben, Lösungen zu finden!

Achim.Pabel@gmx.de
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben