Tasks Killen
Hallo liebe Administratoren,
ich habe ein Problem,
ich hab einen Linux Server (distri Debian 3.1),
benoetige hierfuer ein Script was "abgetorbene" tasks killt.
Gaebe es eine Moeglichkeit soetwas zu stande zu bringen?
Ich kenne mich leider noch zuwenig mit Linux aus um das selbst zu machen.
LG
Arkham
ich habe ein Problem,
ich hab einen Linux Server (distri Debian 3.1),
benoetige hierfuer ein Script was "abgetorbene" tasks killt.
Gaebe es eine Moeglichkeit soetwas zu stande zu bringen?
Ich kenne mich leider noch zuwenig mit Linux aus um das selbst zu machen.
LG
Arkham
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 96151
Url: https://administrator.de/contentid/96151
Ausgedruckt am: 05.11.2024 um 14:11 Uhr
6 Kommentare
Neuester Kommentar
Kannst du etwas mehr über die Tasks verraten? Wenn der Prozess als Zombie, dead o.ä. in der Prozessliste auftaucht ist es ziemlich einfach. Sollte der Status allerdings bei "absturz" noch normal sein, musst du die Funktion des Prozesses irgendwie überprüfen.
Zb. Der erste Fall könnte ein backup-Prozess sein, der abgestorben ist weil ein Problem auf dem SCSI-Bus zum bandlaufwerk vorlag. Status DEAD. Du musst nur die Ausgabe der Prozessliste filtern, den dead-process zur binary (und evt. zum startscript) zuordnen und den Prozess töten, neustarten usw.
Im zweitem Fall könnte ein Webserver aufgrund einer fehlerhaften CGI-Anwendung keine HTTP-Anfragen mehr annehmen. Der Prozess selbst läuft aber aus systemsicht weiter. in diesem Fall musst du den HTTP-Port abfragen und die Ausgabe auswerten. Könntest du im Fall webserver mit einem wget prüfen. Liefert es einen connect-fehler auf port80, ist der webserver tot und du startest ihn neu.
Es gibt auch Monitoring-Tools die genau das machen. Zb. Servicemon oder Watchdog.
Ich hoffe diese oberflächliche Antwort hilft dir bei der Lösungssuche.
Zb. Der erste Fall könnte ein backup-Prozess sein, der abgestorben ist weil ein Problem auf dem SCSI-Bus zum bandlaufwerk vorlag. Status DEAD. Du musst nur die Ausgabe der Prozessliste filtern, den dead-process zur binary (und evt. zum startscript) zuordnen und den Prozess töten, neustarten usw.
Im zweitem Fall könnte ein Webserver aufgrund einer fehlerhaften CGI-Anwendung keine HTTP-Anfragen mehr annehmen. Der Prozess selbst läuft aber aus systemsicht weiter. in diesem Fall musst du den HTTP-Port abfragen und die Ausgabe auswerten. Könntest du im Fall webserver mit einem wget prüfen. Liefert es einen connect-fehler auf port80, ist der webserver tot und du startest ihn neu.
Es gibt auch Monitoring-Tools die genau das machen. Zb. Servicemon oder Watchdog.
Ich hoffe diese oberflächliche Antwort hilft dir bei der Lösungssuche.
Man kann einfach überprüfen ob der Prozess noch Signale annimmt, was er im Normalfall nur tut, wenn er funktionsfähig ist, und wenn nicht, killt man ihn einfach. Einfach mittels 'kill -0 <PID>' ein Signal an den Prozess schicken und schauen ob er drauf reagiert. In einem Bash-Skript dürfte das z.B. so aussehen:
...
if kill -0 ${PID} 2>/dev/null
then
# signal angenommen
else
# signal nicht angenommen
fi
...
Hmh, stimmt. Könnte man kombinieren um einen eigenen Watchdog zu basteln.
Könnte man weitertreiben und eine Liste der zu überwachenden Prozesse aus einer Textfile auslesen. Bei fehler könnte man gleich den Prozess killen und per init-script neu starten.
Genau das macht aber eigentlich watchdog
Bringt dir aber leider nichts wenn der Prozess zwar reagiert, aber keine Anfragen mehr bearbeitet. Könnte zb. auftreten wenn Postfix probleme beim prüfen der DNSBL oder der abfrage einer Datenbank hat. Oder der Apache-Webserver wartet ewigkeiten auf ein Modul. Willst du sichergehen, brauchst du einen Servicemonitor.
if kill -0 $(pidof /usr/sbin/httpd); then echo OK; else echo fehler; fi
Genau das macht aber eigentlich watchdog
Bringt dir aber leider nichts wenn der Prozess zwar reagiert, aber keine Anfragen mehr bearbeitet. Könnte zb. auftreten wenn Postfix probleme beim prüfen der DNSBL oder der abfrage einer Datenbank hat. Oder der Apache-Webserver wartet ewigkeiten auf ein Modul. Willst du sichergehen, brauchst du einen Servicemonitor.
Ja, das stimmt wohl. Service-Monitoring kann man ja recht einfach über Nagios umsetzen. Bei Webservern bevorzuge ich aber zumeist ein eigenes Skript. In die zu überwachende Website baut man am Ende einen eindeutigen HTML-Kommentar ein (z.B. '<!-- test_ping -->') und überprüft dann mittels Skript einfach, ob der Kommentar vorhanden ist.
Das lässt sich natürlich beliebig ausbauen, z.B. mit vorherigem Login über ein Formular u.ä. Man kann es einfach als Cron laufen lassen und kann damit sicher sein, dass eine Seite korrekt ausgeliefert wird.
#!/usr/bin/perl -w
use WWW::Mechanize;
use Net::SMTP;
my $message = '';
my $mailserver = 'localhost';
my $mail_from_addr = 'homepagemonitor@domain.tld';
my $admin_email = 'admin@pager.tld';
sub send_mail_to_admin
{
my ($message) = @_;
my $smtp = Net::SMTP->new($mailserver,
Hello => 'localhost',
Timeout => 60);
$smtp->mail($mail_from_addr);
$smtp->recipient($admin_email);
$smtp->data;
$smtp->datasend("Subject: Alert from Homepage Monitoring");
$smtp->datasend("\n");
$smtp->datasend($message);
$smtp->dataend;
$smtp->quit;
}
my $url = "http://domain.tld/";
my $mech = WWW::Mechanize->new();
$mech->get($url);
my $content = $mech->content();
if($content =~ /test_ping/) {
print "All is fine with homepage on domain.tld.\n";
} else {
$message = "Something is wrong with homepage on domain.tld.\n";
$message .= "Current content:\n";
$message .= $content."\n";
&send_mail_to_admin($message);
}
Das lässt sich natürlich beliebig ausbauen, z.B. mit vorherigem Login über ein Formular u.ä. Man kann es einfach als Cron laufen lassen und kann damit sicher sein, dass eine Seite korrekt ausgeliefert wird.
Feines script. Das könnte man nun noch um die verschiedensten plain-text Protokolle erweitern. Super Idee. Ich hoffe ihm gefällt es auch
Ich verlasse mich eben zu sehr auf die Monitoring-SW. Damit könnte man den Server zuverlässiger prüfen, auch wenn die VPN zum Remotestandort mal ausfällt.
Theoretisch könnte man ja auch in einem Bash-Script per curl solche Prüfungen starten. Werde ich morgen mal probieren (ich mag perl nicht besonders).
Ich verlasse mich eben zu sehr auf die Monitoring-SW. Damit könnte man den Server zuverlässiger prüfen, auch wenn die VPN zum Remotestandort mal ausfällt.
Theoretisch könnte man ja auch in einem Bash-Script per curl solche Prüfungen starten. Werde ich morgen mal probieren (ich mag perl nicht besonders).