make, ping und nc: Exit-Codes, die anders zu deuten sind, als man annimmt

Worum es geht

Bei drei Tools, die ein Agent häufig per Shell aufruft, ist jeweils ein Exit-Code leicht falsch zu interpretieren.

make: "GNU make exits with a status of zero if all makefiles were successfully parsed and no targets that were built failed. A status of one will be returned if the -q flag was used and make determines that a target needs to be rebuilt. A status of two will be returned if any errors were encountered." Ausserhalb von -q tritt Exit-Code 1 bei gewöhnlichen Builds nicht auf: Ein fehlgeschlagenes Rezept (Recipe) führt zu Exit-Code 2. Das Error 1 in der Meldung von make ist der Code des Rezepts, nicht derjenige von make selbst.

ping: "If ping does not receive any reply packets at all it will exit with code 1 ... On other error it exits with code 2. Otherwise it exits with code 0." Exit-Code 1 bedeutet, dass ping korrekt arbeitet und «keine Antwort» meldet, etwa bei einem ausgefallenen Host, einem Firewall-Drop oder einer falschen Adresse, die sich trotzdem auflösen lässt. Exit-Code 2 ist für Fehler von ping selbst reserviert (ungültige Argumente, nicht auflösbarer Name, Berechtigungsprobleme).

nc/ncat: Die Implementierungen unterscheiden sich, und viele (darunter das netcat von OpenBSD) dokumentieren keine formale Tabelle der Exit-Status. Ncat von Nmap tut es: "The exit code reflects whether a connection was made and completed successfully. 0 means there was no error. 1 means there was a network error of some kind ... 2 is reserved for all other errors, like an invalid option or a nonexistent file." Die Codes jeder anderen nc-Variante gelten als ungeprüft, solange nicht ihre eigene Dokumentation konsultiert wurde.

openssl s_client: Die Option -verify dokumentiert einen echten Stolperstein: "Unless the -verify_return_error option is given, the verify operation continues after errors ... As a side effect the connection will never fail due to a server certificate verify failure." Ohne diese Option endet eine abgeschlossene TLS-Sitzung mit Exit-Code 0, selbst bei ungültigem, abgelaufenem oder selbstsigniertem Zertifikat.

Warum es wichtig ist

In jedem dieser Fälle führt die naive Prüfung «0 gut, sonst schlecht» zu einem falschen Schluss: Der -q-Modus von make kehrt die übliche Bedeutung von 1 um, Exit-Code 1 bei ping ist eine legitime Netzwerkbeobachtung und kein Hinweis auf einen fehlerhaften Aufruf, und der Standard-Exit-Code 0 von openssl s_client kann bedeuten, dass eine Verbindung zu einem Angreifer mit ungültigem Zertifikat bestand, nicht dass die Verbindung verifiziert wurde.

So wird es angewendet

• Bei make -q Exit-Code 1 als erwartetes Signal «Neubau nötig» behandeln und die eigentliche Fehlerbehandlung für Exit-Code 2 vorsehen.
• Die Unterscheidung zwischen 1 und 2 bei ping nutzen, um «Host nicht erreichbar» (1, Alarm auf das Ziel sinnvoll) von «ping selbst ist fehlgeschlagen» (2, eigene Argumente prüfen) zu trennen.
• Vorzugsweise nc -z zusammen mit den dokumentierten Codes der jeweiligen Implementierung verwenden oder den Ausgabetext auswerten; nicht davon ausgehen, dass sich die Semantik zwischen OpenBSD nc, GNU netcat und Ncat übertragen lässt.
• Bei openssl s_client-Aufrufen für automatisierte Zertifikatsprüfungen stets -verify_return_error und -verify_hostname <name> angeben. Ohne die erste Option sagt Exit-Code 0 nichts über das Zertifikat aus, ohne die zweite liefert auch ein gültiges Zertifikat, das für einen anderen Namen ausgestellt wurde, Exit-Code 0.

Stolpersteine

• Ein Skript wie make -q; [ $? -eq 0 ] || echo "build broken": Ein Exit-Code 1 von -q bedeutet das Gegenteil von «defekt».
• Ein blosses openssl s_client ... ; echo $? als Prüfung der Zertifikatsvalidierung zu betrachten.