Diskussion:Signal (Unix)

Hallo, die signal tabelle sollte abgeaendert werden. Bei einigen Unix'n ist sie anders definiert. --Lofor 13:04, 24. Sep 2006 (CEST)

Ja, die Tabelle hat wenig Ähnlichkeit mit aktuellem UNIX. Vor allem stimmen die Singalnummern nicht und es ist fraglich ob es sinnvoll ist diese Nummern überhaupt anzugeben Schily 21:05, 10. Mär. 2010 (CET)

Die Signalnummern stimmen sehr wohl, nur sind sie nicht überall gleich, deswegen habe ich die Tabelle nun ergänzt. In der Spalte „C“ steht jetzt das, was man üblicherweise auf einem Linux-x86/AMD64 erwartet. Die GLIBC-Spalte folgt fast deckungsgleich den BSDs (1-15 seit mindestens 2.9.1 BSD, ab 2.10 BSD dann 1-28;30-31, ab 4.3BSD kommt 29 hinzu; das aktuelle Freebsd hat ein 32. Signal – das dürfte dann auch für OS X gelten); ich denke mal das werde ich bei Gelegenheit noch einarbeiten. --CHF (Diskussion) 22:51, 20. Jun. 2013 (CEST)

Es fehlt der gesamte Background: - Signale als Teil der Programmiersprache C - Signale als wichtiger Mechanismus der Unix-Betriebssysteme

Ferner: die Signalliste sollte sich auf den Unix-Standard beziehen (www.opengroup.org/susv3/).Eglatz (Diskussion | Beiträge) 14:30, 28. Okt. 2010 (CEST))

Ich denke nicht; es sollten vielmehr die gebräuchlichen unixartigen Systeme abgedeckt sein. --CHF (Diskussion) 22:51, 20. Jun. 2013 (CEST)

Eine bessere Version dieser Seite ist unter en.wikipedi.org/wiki/Unix_signal zu finden und sollte den Ausgangspunkt für eine Ueberarbeitung bilden (nicht signierter Beitrag von Eglatz (Diskussion | Beiträge) 14:30, 28. Okt. 2010 (CEST))

Viel wichtiger als die Nummern erscheint mir momentan, eine deutschsprachige Bedeutung anzugeben und die „Standardwirkung“ der Signale zu beschreiben. --CHF (Diskussion) 22:51, 20. Jun. 2013 (CEST)

Übersetzung SIGHUP

SIGHUP hat doch nichts mit Blockierung zu tun. Ursprünglich war das doch dafür gedacht, wenn eine Einwahlverbindung beendet wird oder abbricht. Mir fällt aber gerade keine passende kurze Übersetzung dazu ein. --MiLuZi (Diskussion) 12:28, 16. Aug. 2020 (CEST)

Richtig!

Blockiert ist ein Terminal, wenn Strg-S gedrückt wurde. Diese Blockade hat nichts mit SIGHUP zu tun. LEO gibt als erste Bedeutung aufgelegt an, daher Unterbrechung der Verbindung zum Kontrollterminal.

death of controlling process wurde wegen einer Mehrdeutigkeit nicht übersetzt. Ende des Kontrollprozess kommt in Verbindung mit einem Terminal vor und ist mit Unterbrechung der Verbindung zum Kontrollterminal ausreichend erklärt. Bei einem Steuerprogramm ist death irreführend.

Die Worte controlling und kontrollieren sind falsche Freunde. Im Englischen ist „Macht ausüben“, „steuern“ oder „regeln“ gemeint. Im Deutschen steht kontrollieren für „prüfen“ oder „überwachen“.

Wegen dieser Mehrdeutigkeit will ich Kontroll aus der Übersetzung entfernen.

controlling terminal mag ein Fachausdruck sein. Der wäre erklärungsbedürftig, sinnvollerweise in einem eigenen Artikel (Steuerterminal oder Controlling Terminal). Außer dem Sprachgebrauch in meiner Arbeitsumgebung habe ich keinen Beleg für die Verwendung dieses Ausdrucks. Man kann den Sprachgebrauch im Alltag als trivial auffassen, dann ist kein Beleg notwendig.

Gibt es Meinungen dazu? --Steg~dewiki (Diskussion) 19:21, 27. Aug. 2022 (CEST)

Einleitung

Die Einleitung sollte neu formuliert werden. Es folgen zu jedem Satz Hinweise.

• Bei Verwendung des Betriebssystems Unix ist ein Signal eine Systemnachricht an einen laufenden Prozess.

Die Systemnachricht richtet sich zunächst an den Kernel. Weiter unten ist beschrieben, dass die meisten Signale den Prozess beenden. In diesen Fällen räumt der Kenel den Prozess weg, der Prozess selbst empfängt das Signal nicht. Ähnlich ist es, wenn das Signal ignoriert wird. Nur wenn das Signal abgefangen wird, ist der Prozess beteiligt.

Der Prozess muss nicht laufen. Ein Signal kann auch einen wartenden / schlafenden / blockierten / gestoppten (SIGCONT!) Prozess betreffen. Nur eine ungültige Prozess Identifikation, die von einem beendeten Prozess (Zombie) stammen könnte, funktioniert nicht.

Darüber hinaus werden Rechte geprüft (gleiche Benutzerkennung von Absender und Empfänger oder Absender ist root, SELinux, Linux Capabilities).

• Signale sind eine primitive Form der Interprozesskommunikation.

primitiv ist fraglich.

Für primitiv gibt Wiktionary (https://de.wiktionary.org/wiki/primitiv) an erster Stelle die Bedeutung ursprünglich; auf einem frühen, überholten Entwicklungsstadium basierend. Das Wort ursprünglich mag richtig sein, überholtes Entwicklungsstatium passt nicht. überholt im Sinne von veraltet ist bei einem Verfahren, das in allerneuesten Systemen zur Anwendung kommt, nicht passend. Als weitere Bedeutung ist niveaulos angegeben, erläutert als keine geistige Höhe aufweisend. Das ist abwertend und unangemessen. Eine dritte Bedeutung ist nicht ausgereift. Ein seit Jahrzehnten etabliertes Verfahren hat Reife.

Wenn ein englischer Fachbegriff übernommen wurde, etwa en:Primitive data type, ist das erklärungsbedürftig oder kann durch einfacher Datentyp ersetzt werden.

Vorschlag: Signale sind eine einfache, wirkungsvolle Form der Interprozesskommunikation.

• Die meisten Signale bewirken auch eine Aktion – meist das Beenden des Prozesses.

Jedes Signal bewirkt eine Aktion. Weiter unten ist ignorieren als Aktion angegeben. Wenn ein Signalhandler gestartet wird, ist das eine Aktion.

Beim System V war für jedes Signal die Voreinstellung, den Prozess zu beenden.

Vorschlag: Die meisten Signale bewirken das Beenden des Prozesses.

• Andere hingegen dienen lediglich der Information (z. B. SIGWINCH) oder können einen Prozess anhalten (SIGSTOP).

Das passt nicht. Das Standardverhalten zu SIGWINCH ist, das Signal zu ignorieren, dann kommt keine Information. Wird ein Signalhandler installiert, ist das Starten des Signalhandlers wohl eine Aktion.

Der Umgang mit Information sollte im Artikel erläutert werden.

Viele Signale beenden den Prozess. Die Signalnummer wird in den Speicherauszug eingetragen. Der Empfänger von SIGCHLD bekommt die Nummer durch die Funktion wait, waitpid usw.

Anhalten ist als Aktion benannt.

• Es gibt auch vom Benutzer frei verwendbare Signale (SIGUSR1 und SIGUSR2).

Der Benutzer wählt die Signale nicht, das macht der Softwareentwickler. Die Abkürzung USR kommt aus einer Zeit, als viele Unix-Benutzer selbst programmiert haben. Das ist nicht mehr üblich. Das Symbol / die Benennung wurde nicht geändert.

• Einige Signale können vom Prozess abgefangen oder unterdrückt werden.

Bis auf zwei (SIGKILL, SIGSTOP) Ausnahmen können alle Signale abgefangen oder ignoriert (unterdrückt) werden.

• So fangen z. B. manche Serverprogramme (im Unix-Jargon „Daemon“) SIGUSR1 oder SIGUSR2 ab und lesen dann ihre Konfigurationsdateien neu ein.

Bei System V gab es kein SIGUSR1 / SIGUSR2, daher ist SIGHUP üblich und wird neben SIGUSR1 und SIGUSR2 verwendet.

--Steg~dewiki (Diskussion) 23:10, 3. Jan. 2023 (CET)