Unterschale in den Hintergrund setzen oder Befehl in den Hintergrund stellen

Ich habe zwei Bash-Skripte, die versuchen, Hosts zu überprüfen, die aktiv sind:

Skript 1:

#!/bin/bash 
for ip in {1..254}; do
    ping -c 1 192.168.1.$ip | grep "bytes from" | cut -d" " -f 4 | cut -d ":" -f 1 &
done

Skript 2:

#!/bin/bash 
for ip in {1..254}; do
    host=192.168.1.$ip
    (ping -c 1 $host > /dev/null 
    if [ "$?" = 0 ]
    then 
        echo $host
    fi) &
done

Da ich einen großen Bereich überprüfe, möchte ich jeden Ping-Befehl parallel verarbeiten. Mein zweites Skript scheint jedoch fehlgeschlagene Verzweigungsversuche aufgrund von Ressourcenbeschränkungen nicht erneut zu versuchen. Dies führt dazu, dass das zweite Skript inkonsistente Ergebnisse aufweist, während mein erstes Skript konstante Ergebnisse liefert, obwohl beide zeitweise nicht verzweigen. Kann mir das jemand erklären? Gibt es überhaupt eine Möglichkeit, ausgefallene Gabeln erneut zu versuchen?

Es gibt bereits eine Antwort, die ein verbessertes Code-Snippet für die Aufgabe liefert, auf die sich die ursprünglichen Posterfragen bezogen, während sie möglicherweise noch nicht direkter auf die Frage geantwortet hat.

Die Frage betrifft Unterschiede von

• A) Hintergrund eines "Befehls" direkt, vs.
• B) Eine Unterschale in den Hintergrund stellen (dh mit einer ähnlichen Aufgabe)

Lassen Sie uns diese Unterschiede überprüfen, indem wir 2 Tests ausführen

# A) Backgrounding a command directly
sleep 2 & ps

Ausgänge

[1] 4228
  PID TTY          TIME CMD
 4216 pts/8    00:00:00 sh
 4228 pts/8    00:00:00 sleep

während

# A) backgrounding a subhell (with similar tas)
( sleep 2; ) & ps

gibt so etwas aus wie:

[1] 3252
  PID TTY          TIME CMD
 3216 pts/8    00:00:00 sh
 3252 pts/8    00:00:00 sh
 3253 pts/8    00:00:00 ps
 3254 pts/8    00:00:00 sleep

** Testergebnisse:**

In diesem Test (der nur a sleep 2ausführt) unterscheidet sich die Subshell-Version tatsächlich, da zwei untergeordnete Prozesse (dh zwei fork()/ execOperationen und PID) und damit mehr als der direkte Hintergrund des Befehls verwendet würden.

In der script 1Frage war der Befehl jedoch kein einzelner, sleep 2ssondern ein pipevon 4 Befehlen, die wir in einem zusätzlichen Fall testen

• C) Hintergrund einer Pipe mit 4 Befehlen

# C) Backgrounding a pipe with 4 commands
sleep 2s | sleep 2s | sleep 2s | sleep 2s & ps

ergibt dies

[2] 3265
  PID TTY          TIME CMD
 3216 pts/8    00:00:00 bash
 3262 pts/8    00:00:00 sleep
 3263 pts/8    00:00:00 sleep
 3264 pts/8    00:00:00 sleep
 3265 pts/8    00:00:00 sleep
 3266 pts/8    00:00:00 ps

und zeigt, dass das in der Tat script 1eine viel höhere Belastung in Bezug auf PIDsund fork()s wäre.

Als grobe Schätzung hätte das Skript etwa 254 * 4 ~ = 1000 PIDs und damit sogar mehr als script 2bei 254 * 2 ~ = 500 PIDs verwendet. Ein Problem, das aufgrund der Erschöpfung der PIDs auftritt, scheint noch unwahrscheinlich, da höchstens Linux-Boxen

$ cat /proc/sys/kernel/pid_max
32768

gibt Ihnen 32x mal die auch für Fall benötigt PIDs script 1und die Prozesse / beteiligten Programme (dh sed, pingscheinen, usw.) auch unwahrscheinlich , dass die inkonstant Ergebnisse zu verursachen.

Wie von Benutzer @derobert erwähnt, bestand das eigentliche Problem hinter dem Fehler darin, scriptsdass der waitBefehl fehlte. Dies bedeutet, dass nach dem Hintergrund der Befehle in der Schleife das Ende des Skripts und damit die Shell dazu führte, dass alle untergeordneten Prozesse beendet wurden.

Dies wird das tun, was Sie erwarten:

#!/bin/bash
function_ping(){
    if ping -c 1 -w 5 $1 &>/dev/null; then 
        echo "UP: $1"
    else
        echo "DOWN $1" 
    fi
}
for ip in {1..254}; do
        function_ping 192.168.1.$ip &  
done
wait 

Speichern Sie es als Parallelping und führen Sie es aus.

Es hilft dir? Es kann in eine große Funktion umgewandelt werden, die auch in einer schnellen while-Schleife verwendet werden kann, sodass Sie Ihre Fantasieprogrammierung damit verwenden können.

Hinweis: Sie müssen bash verwenden.