(LINUX) Den Schuft herausfinden, der ein Signal schickt ;-)

[Bio]

Sup!

Ich bastele gerade an ein paar Skripten herum, die beim Start des Rechners in der ip-up.local stehen und ein paar Dienste starten sollen, die in Perl geschrieben sind.

Sehr merkwuerdigerweise scheint dieses Starten bei einigen Skripten zu funktionieren. Bei einigen funktioniert es nicht.
Dabei sind alle Skripten tadellos lauffaehig, wenn man sie von Hand startet, und die Leute auf der PPPD-Mailingliste behaupten, es gaebe keine besonderen Einschraenkungen oder Timeouts fuer Programme, die per ip-up.local gestartet werden.
Zudem sind die Skripten eigentlich ganz aehnlich; die einzige Ausnahme ist, daß dieses eine Skript, das nicht funktioniert, auf das Netzwerk zugreift und wesentlich groesser ist als die anderen.

Es sieht ausserdem so aus, als ob das Skript von irgendwem per Signal abgeschossen wird. Und nun wuerde ich gerne wissen, ob es eine Moeglichkeit gibt, herauszufinden, wer in meinem System wem Signale schickt bzw. wer einem Perl-Skript ein Signal geschickt hat. Das muss doch irgendwie gehen.

Gruesse,

Bio

[Frank Schönmann]

hi!

Es sieht ausserdem so aus, als ob das Skript von irgendwem per
Signal abgeschossen wird. Und nun wuerde ich gerne wissen, ob es
eine Moeglichkeit gibt, herauszufinden, wer in meinem System wem
Signale schickt bzw. wer einem Perl-Skript ein Signal geschickt hat.
Das muss doch irgendwie gehen.

Zuerst empfehle ich mal die Lektüre von perldoc perlipc, da steht
schon einiges über Interprocess Communication drin. Außerdem gibt es
noch das Modul POSIX, mit dem sich viele (alle?) POSIX-Funktionen
aufrufen lassen. Wenn es also eine passende POSIX-Funktion gibt, dann
kannst du damit feststellen, woher das Signal kommt. Und alles andere
als POSIX-Funktionen hat sowieso keinen Wert auf 'nem Unix-System :)

bye, Frank!

[Christoph Zurnieden]

Hallo,

Es sieht ausserdem so aus, als ob das Skript von irgendwem per
Signal abgeschossen wird. Und nun wuerde ich gerne wissen, ob es
eine Moeglichkeit gibt, herauszufinden, wer in meinem System wem
Signale schickt bzw. wer einem Perl-Skript ein Signal geschickt hat.
Das muss doch irgendwie gehen.

"Irgendwie" ja, allerdings tragen die normalen Signale (Dein Script wird wohl ein SIGINT oder SIGKILL bekommen) keinen Absender.
Zumindest keinen direkt lesbaren ;-)

Zuerst empfehle ich mal die Lektüre von perldoc perlipc, da steht
schon einiges über Interprocess Communication drin. Außerdem gibt es
noch das Modul POSIX, mit dem sich viele (alle?) POSIX-Funktionen
aufrufen lassen.

'perldoc POSIX' (funktioniert zumindest hier)

The POSIX module permits you to access all (or nearly all)
       the standard POSIX 1003.1 identifiers.

und ein wenig später auch noch die Warnung:

Perl does not attempt to verify POSIX compliance.  That
       means you can currently successfully say "use POSIX",  and
       then later in your program you find that your vendor has
       been lax and there's no usable ICANON macro after all.
       This could be construed to be a bug.

Das sind also nicht gerade viele (POSIX 1003.1 ist auch schon etwas älter)

Was Du auf jeden Fall gebrauchen kannst, ist:

sigaction
               Detailed signal management.  This uses
               POSIX::SigAction' objects for the action' and
               oldaction' arguments.  Consult your system's                sigaction' manpage for details.

Synopsis:

sigaction(sig, action, oldaction = 0)

Returns `undef' on failure.

Zumindest unter C kann man damit alle Signale außer SIGKILL abfangen und zumindest eine Ausgabe erzeugen, an welchem Punkt dies geschehen ist. Das sollte eigentlich schon einmal _etwas_ weiterbringen.

BTW: Bist Du Dir auch sicher Dir kein SIGSEGV eingefangen zu haben? ;-)

Wenn es also eine passende POSIX-Funktion gibt, dann
kannst du damit feststellen, woher das Signal kommt. Und alles andere
als POSIX-Funktionen hat sowieso keinen Wert auf 'nem Unix-System :)

Hey, und was ist mit den GNU-Extensions? ;-)))

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Was Du auf jeden Fall gebrauchen kannst, ist:

sigaction
               Detailed signal management.  This uses
               POSIX::SigAction' objects for the action' and
               oldaction' arguments.  Consult your system's                sigaction' manpage for details.

Synopsis:

sigaction(sig, action, oldaction = 0)

Returns `undef' on failure.

Zumindest unter C kann man damit alle Signale außer SIGKILL
abfangen und zumindest eine Ausgabe erzeugen, an welchem Punkt
dies geschehen ist. Das sollte eigentlich schon einmal _etwas_
weiterbringen.

In Perl benutzt mal ueblicherweise aber den %SIG-Hash, einen mit
'tie' gebundenen Hash -- z. B. $SIG{INT} = &function;

Gruesse,
 CK

[Christoph Zurnieden]

Hoi,

Was Du auf jeden Fall gebrauchen kannst, ist:

sigaction(sig, action, oldaction = 0)

In Perl benutzt mal ueblicherweise aber den %SIG-Hash, einen mit
'tie' gebundenen Hash -- z. B. $SIG{INT} = &function;

Naja, komme aus dem C-Lager, wenn ich den ersten nehme, muß ich nicht umlernen ;-)

Alternativ hätte ich natürlich auch den bei Perl stets(!) passenden Spruch loswerden können:

"So geht's natürlich auch."

SCNR ;-)))

Aber mal ernsthaft: bevor ich mich durch die Perlquellen wühlen muß (For the extremly hardboiled only! ;-) und ganz abgesehen von der Syntax: wo ist genau der Unterschied?

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Naja, komme aus dem C-Lager, wenn ich den ersten nehme, muß ich
nicht umlernen ;-)

Och, ich komme auch von da. Aber verschiedene Angehensweisen
erweitern unter Umstaenden den Horizont :-) Das ist auch der Grund,
warum ich Ruby z. B. gelernt habe.

Alternativ hätte ich natürlich auch den bei Perl stets(!)
passenden Spruch loswerden können:

"So geht's natürlich auch."

SCNR ;-)))

das gilt nicht nur fuer Perl ;-)

Aber mal ernsthaft: bevor ich mich durch die Perlquellen wühlen
muß (For the extremly hardboiled only! ;-) und ganz abgesehen von
der Syntax: wo ist genau der Unterschied?

Es ist portabler. Das POSIX-Modul implementiert eben nicht immer
alles. Ausserdem bietet %SIG zwei zusaetzliche (Perl-Interne)
Signale: SIG__WARN__ und SIG__DIE__.

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Naja, komme aus dem C-Lager, wenn ich den ersten nehme, muß ich
nicht umlernen ;-)

Och, ich komme auch von da. Aber verschiedene Angehensweisen
erweitern unter Umstaenden den Horizont :-) Das ist auch der Grund,
warum ich Ruby z. B. gelernt habe.

Naja, aber zumindest reingeschaut habe ich. Interessant ist sie schon!

Aber bei dem Stichwort habe ich einmal gezählt, was ich so im Laufe meiner Jahre an Sprachen gelernt hatte, von denen ich nun zumindest die Syntax beherrsche (der Rest aus den Manpages ;-) und kam auf 18!

Mein Gott, was soll ich mit dem ganzem Driss?

Vor allem sind da noch so völlig überflüssige Sachen wie DOS-Shellscript, VBScript und VB dabei! >;->

Alternativ hätte ich natürlich auch den bei Perl stets(!)
passenden Spruch loswerden können:
"So geht's natürlich auch."

das gilt nicht nur fuer Perl ;-)

Aber nur da _immer_!
Was man auch macht, es gibt immer eine Alternative.
Der letzte Satz gilt natürlich rekursiv. ;-)

Aber mal ernsthaft: bevor ich mich durch die Perlquellen wühlen
muß (For the extremly hardboiled only! ;-) und ganz abgesehen von
der Syntax: wo ist genau der Unterschied?

Es ist portabler.

Nun ja, das war schon klar ;-)

Das POSIX-Modul implementiert eben nicht immer
alles. Ausserdem bietet %SIG zwei zusaetzliche (Perl-Interne)
Signale: SIG__WARN__ und SIG__DIE__.

Aha, wieder etwas gelernt.
Sind die evt Geschwindigkeitsunterschiede signifikant?

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Och, ich komme auch von da. Aber verschiedene Angehensweisen
erweitern unter Umstaenden den Horizont :-) Das ist auch der Grund,
warum ich Ruby z. B. gelernt habe.

Naja, aber zumindest reingeschaut habe ich. Interessant ist sie
schon!

Oh ja, sehr interessant :-)

Aber bei dem Stichwort habe ich einmal gezählt, was ich so im
Laufe meiner Jahre an Sprachen gelernt hatte, von denen ich nun
zumindest die Syntax beherrsche (der Rest aus den Manpages ;-)
und kam auf 18!

Tja, da komme ich auf 14 ;-)

Vor allem sind da noch so völlig überflüssige Sachen wie
DOS-Shellscript, VBScript und VB dabei! >;->

*g* bei mir auch. Wobei die letzteren beiden ich nicht freiwillig
gelernt habe.

Das POSIX-Modul implementiert eben nicht immer
alles. Ausserdem bietet %SIG zwei zusaetzliche (Perl-Interne)
Signale: SIG__WARN__ und SIG__DIE__.

Aha, wieder etwas gelernt.
Sind die evt Geschwindigkeitsunterschiede signifikant?

Die Perldoc sagt dazu nichts. Ich kann es leider auch nicht
ausprobieren, ich habe hier nur einen Win2k-Rechner. Und da ist
POSIX::sigaction nicht implementiert.

Gruesse,
 CK

[Frank Schoenmann]

hi!

Naja, komme aus dem C-Lager, wenn ich den ersten nehme, muß ich
nicht umlernen ;-)
Och, ich komme auch von da. Aber verschiedene Angehensweisen
erweitern unter Umstaenden den Horizont :-) Das ist auch der Grund,
warum ich Ruby z. B. gelernt habe.

Was soll an Ruby den Horizony erweitern? Es basiert auf den gleichen Para-
digmen wie andere imperative Programmiersprachen auch...

bye, Frank!