Auf den Punkt gebracht

Klug gesperrt

05/12, S. 90: Im Bash Bashing über das richtiges Locking fehlt ein Hinweis auf das Tool Flock. Meiner Erfahrung nach ist es die beste Lösung, wenn man sich nicht um das Aufräumen der Lockfiles kümmern möchte. Das geht, in dem der Programmierer die Skriptdatei selbst als Lockfile verwendet. Nach einem Absturz oder wenn der Prozess gekillt wurde, bleibt kein Lock zurück. Listing 1 zeigt eine Shellsitzung, die das verwendet.

01 server:~/tmp # cat test.sh
02 #!/bin/bash
03 sleep 5
04 echo fertig geschlafen
05 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
06 [1] 62643
07 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
08 [2] 62647
09 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
10 [3] 62649
11 server:~/tmp # flock -w 1 -x test.sh -c ./test.sh || echo lock nicht bekommen &
12 [4] 62654
13 server:~/tmp # lock nicht bekommen
14 lock nicht bekommen
15 lock nicht bekommen
16 fertig geschlafen

Georg Höllrigl, per E-Mail

Stiefkind Locking

05/12, S. 90: Zum Bash Bashing 20: Die Themen Locking, Code-Serialisierung und Race Conditions werden meiner Meinung nach unterschätzt. Der Code des Tools »screen« beispielsweise geht das Locking falsch an (Listing 2), was als Debian Bug #653434 bekannt ist. Leider arbeitet offenbar niemand mehr an dem Projekt. Die Alternative Tmux, die das Linux-Magazin schon einmal vorgestellt hat, enthielt bis vor Kurzem ebenfalls einen Locking-Fehler. Hier sind die Maintainer allerdings sehr aktiv und haben ein Quelltext-Patch von mir rasch übernommen.

01 if (access(SockPath, F_OK)) {
02   if (mkdir(SockPath, 0700) == -1)
03     Panic(errno, "Cannot make directory '%s'", SockPath);
04 }

Tim Rühsen, per E-Mail