Re: 4.4 -> 4.7: /bin/sh very broken?

<de-bsd-questions(at)de.FreeBSD.org> aka Oliver Fromme schrieb
mit Datum Sat, 15 Mar 2003 11:51:40 +0100 (CET) in m2n.de.fbsd.questions:

|Peter Much <pmc(at)citylink.dinoex.sub.org> wrote:
| > hat sich schon jemand darueber beschwert, dass zwischen 4.4 und 4.7
| > die /bin/sh zerdengelt wurde?
|
|Nicht daß ich wüßte.
|
| > Gegeben sei folgendes Binary:
| > ----------------------
| > #include <unistd.h>
| > main() {
| > alarm(2);
| > sleep(3);
| > }
| > ----------------------
|
|Daß dieser Source »broken« ist, ist Dir schon klar, oder?

Dieser "Source" diente dazu, um *nachzustellen*, was da eigentlich
vorgeht. Zuvor hab ich eine ganze weile verzweifelt nach dem
Syntaxfehler in meinem Shellscript gesucht. Und da der Effekt
in der Produktivanwendung in zufaelliger Manier nur etwa einmal
bei 100 Aufrufen passiert, ist es nicht das, was zu suchen Laune
macht. Ich war dann vielmehr ziemlich froh, dass ich es ueberhaupt
nachstellen konnte.

|Mal von den offensichtlichern Fehlern abgesehen: Wenn man
|ein SIGALRM auslöst, sollte man dafür auch einen Signal-
|Handler installieren. Sobald man das tut, funktioniert
|nämlich Dein Beispiel völlig problemlos.

Warum sollte man? So wie hier verwendet ist das doch genau
derselbe Effekt als wenn ich von aussen mit kill draufhaue,
oder etwa nicht?
Und ich sehe -auch in jenem Fall eines kill von aussen- nicht
wirklich eine Rechtfertigung, warum dann das den Binary-Aufruf
enthaltene Shellscript (das ja den Returncode des Binary ohnehin
auswerten moechte!) durch Syntaxfehler komplett in die Wueste
gehen duerfte.

Denn die Katastrophe wuerde ja dergestalt ganz identisch passieren
bei JEDER Art von signal, einschliesslich des regulaeren Terminate,
Sighup, etc.etc. (nur die jeweiligen Meldungsstrings unterscheiden
sich; das heisst dann eben "Terminate" statt "Alarm cloch").
Und Du kannst doch nicht ernsthaft behaupten, dass man jetzt fuer
ALLE denkbaren Signals einen Handler installieren muesse, oder
selektive Programme nicht mehr killen duerfe, weil einem sonst die
Shellscripts um die Ohren fliegen!

| > Konkret fliegt mir damit naemlich mein sucknews immer wieder um die
| > Ohren.
|
|Dann sollte man den Bug in sucknews fixen.

Es ist darinnen sicher nicht der einzige: Ich wuerde vom allgemei-
nen Geruch her nicht behaupten, dass das sucknews irgendeinen Preis
fuer robuste Programmierung verdient.
Ich habe allerdings auch erstens beim schnellen Quersuchen durch
die Sosze von sucknews weder einen Aufruf von alarm() noch von
sigitimer() (oder wie das nun heissen mag) gefunden und bin mir
also gar nicht ganz klar, was die da eigentlich treiben. Zweitens
wird das sucknews selber im konkreten Stoerungsfall scheinbar
_NICHT_ durch sigalarm beendet (im Gegensatz zu meinem beispielsource),
denn es laeuft korrekt bis zu seinem vorgesehenen Programmende.
Und drittens hat das Sucknews im konkreten Stoerungsfall auch
ueberhaupt keinen Anlass, einen Alarm zu triggern, weil die
Netzverbindung ok und der ganze Job in Sekunden erledigt ist.
Was da also vorgeht, ist hoechlich merkwuerdig, und ich haette womoeg-
lich noch Lust, mich mit best practices of Timer- und Signal-Handling
zu beschaeftigen, ich habe aber nur schwerlich Lust, eine offenbar
von race-Conditions durchsetzte Sosze zu entwanzen - um mir womoeglich
dann von irgendeinem Pinguin sagen zu lassen, dass das auf Linux
doch bisher immer problemlos gelaufen sei. (Genau das Problem habe
ich hier naemlich schon rumstehen in Form eines -gar nicht so ganz
billigen- Scanners, der auch angeblich "unter Linux mit SANE problemlos
laeuft", aber eben leider nicht unter FreeBSD: da laeuft der Steppermotor
dummerweise rueckwaerts.)

| > Waer also nett, wenn mal jemand mit 4.7 das kurz reproduzieren
| > koennte.
|
|Mit dem fehlerhaften C-Source kann ich es in der Tat repro-
|duzieren. Das muß natürlich nicht viel heißen. Ob die sh
|in 4.7 einen Bug hat oder nicht, kann man daraus nicht un-
|bedingt schließen (aber auch nicht ausschließen). Zumin-
|dest könnte sie sich im Falle von Fehlern anderer Programme
|ein wenig robuster verhalten.

Das hast Du sehr schoen vorsichtig formuliert.:-))
Ich wuerde mal sagen, dass der Signalname-String ZWEIMAL
ausgegeben wird - einmal wie bisher auf den tty des Shellscripts
bzw. dessen Umleitung, und dann nochmal angehaengt an den stdout
der naechstbesten aufgerufenen Subshell, das ist irgendwie ziem-
lich ueberfluessig (und in Faellen wie diesem eben ausgesprochen
stoerend).

| > Shellscripts will ich sowas nicht (wenn da ein Prozess durch signal
| > beendet, dann ist das Absicht), deswegen nehme ich da ja auch
| > /bin/sh und keine komfortable Bloatshell.
|
|Die /bin/sh ist eigentlich eine komfortable Bloatshell.

Ja, den Verdacht hab ich seit 10 Minuten (als Bernd Walters
Beitrag in mein Postkoerbchen kam und ich geschaut hab, was
signal 20 eigentlich ist) auch.

Gruss
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 16 Mar 2003 - 01:37:53 CET