Port unter Linux wieder freigeben ?
- Ersteller Rommel
- Erstellt am
Rommel
Inventar
Hi,,
folgendes. Eine Anwendung kommuniziert in das Internet z.sbp. über den Port 15000. Und schmiert diese Anwendung ab.
Bei dem Neustart dieser Anwendung wird eine Fehlermeldung ausgegeben das der Port ( in diesem Fall ja der 15000er ) bereits in Verwendung ist und daher nicht genutzt werden kann.
Wie also kann ich so einen Port "reseten" damit er wieder frei ist ?
Gruß
Rommel
folgendes. Eine Anwendung kommuniziert in das Internet z.sbp. über den Port 15000. Und schmiert diese Anwendung ab.
Bei dem Neustart dieser Anwendung wird eine Fehlermeldung ausgegeben das der Port ( in diesem Fall ja der 15000er ) bereits in Verwendung ist und daher nicht genutzt werden kann.
Wie also kann ich so einen Port "reseten" damit er wieder frei ist ?
Gruß
Rommel
eigentlich sollten, wenn ein prozess beendet wird, alle resourcen, also auch die ports, wieder freigegeben werden.
kann es sein, dass das proggie das du meinst, irgendwie forkt oder so, und nach dem abka**en noch ein prozess im speicher haengt?
_fire
kann es sein, dass das proggie das du meinst, irgendwie forkt oder so, und nach dem abka**en noch ein prozess im speicher haengt?
_fire
Rommel
Inventar
Der Prozess ist einwandrei gekillt. Nur ein init6 also ein durchstarten gibt die Ressource wieder frei. Weiß der Geier warum
DarkSpirit
Cadet
- Mitglied seit
- 14.04.2004
- Beiträge
- 43
- Renomée
- 0
Oder einfacher: Mit "netstat -anp" den Verursacher finden und killen.
PuckPoltergeist
Grand Admiral Special
Der Verursacher ist ja schon tot, das ist das Problem. Ein Programm, welches mit SIGKILL beendet wird bzw. sich selbst so "beendet" gibt alloziierte Ressourcen nicht wieder frei. Das sollte sich aber als root mit einem entsprechenden tool realisieren lassen.
Rommel
Inventar
und das da wäre ?
@rommel:
jo, PuckPoltergeist hat recht. aber eigentlich sollte das ja so wenig wie moglich geschehen.
killst du das proggie, oder killt es sich selber?
hast du das proggie selber geschrieben? dann koenntest du ja evt. einen entsprechenden singnal handler einbauen. wobei ich mir gerade nicht so sicher bin, ob die sigkill abfangen kannst.
_fire
jo, PuckPoltergeist hat recht. aber eigentlich sollte das ja so wenig wie moglich geschehen.
killst du das proggie, oder killt es sich selber?hast du das proggie selber geschrieben? dann koenntest du ja evt. einen entsprechenden singnal handler einbauen. wobei ich mir gerade nicht so sicher bin, ob die sigkill abfangen kannst.
_fire
Rommel
Inventar
Original geschrieben von _fire
@rommel:
jo, PuckPoltergeist hat recht. aber eigentlich sollte das ja so wenig wie moglich geschehen.
hast du das proggie selber geschrieben? dann koenntest du ja evt. einen entsprechenden singnal handler einbauen. wobei ich mir gerade nicht so sicher bin, ob die sigkill abfangen kannst.
_fire
Nein,, das Progi hab ich nicht geschrieben. Manchmal ist es so das es nicht mehr reagiert. Dann wird der Prozess manuell gekillt. Der Port bleibt aber weiterhin dicht. Das heißt im klartext. Wenn ich dann versuche das Progi wieder zu starten meldet er sich mit einer Fehlermeldung das der gewünschte PORT schon in Benutzung ist. Und damit ENDE im GELÄNDE
PuckPoltergeist
Grand Admiral Special
Original geschrieben von _fire
hast du das proggie selber geschrieben? dann koenntest du ja evt. einen entsprechenden singnal handler einbauen. wobei ich mir gerade nicht so sicher bin, ob die sigkill abfangen kannst.
_fire
SIGKILL und SIGSTOP lassen sich nicht abfangen. Das ist ja gerade der Sinn von SIGKILL, dass man den Prozess auch dann noch los wird, wenn er auch nicht mehr auf SIGTERM reagiert.
DarkSpirit
Cadet
- Mitglied seit
- 14.04.2004
- Beiträge
- 43
- Renomée
- 0
IMHO macht das zwar nicht das Programm, aber der Kernel. Speicherleichen gibt es dabei nicht, soweit ich weiß, aber ich lasse mich gerne eines besseren belehren
PuckPoltergeist
Grand Admiral Special
Dynamisch alloziierter Speicher wird nicht wieder frei gegeben, sofern es das Programm nicht selber macht (geht bei SIGKILL ja schlecht). Genauso geöffnete Dateien und Ports. Wenn das Programm diese Ressourcen (zur Laufzeit alloziiert) nicht selber wieder frei gibt, bleiben die bis in alle Ewigkeit geöffnet.
H
hct
Guest
Bitte was? Wo hast du das denn her? Das ist natürlich nicht richtig.
Damit wäre programmieren ja der Horror. Wenn einem 20 mal das Programm gecrasht ist muss man neu booten weil kein Speicher mehr frei wäre.
PuckPoltergeist
Grand Admiral Special
Jepp, so ist das auch. Das gleiche passiert, wenn das Programm beendet wird, ohne den dynamisch alloziierten Speicher wieder frei zu geben. Das nennt sich dann Speicherleck.
H
hct
Guest
Ein Speichleck gibt es nur zu Laufzeit eines Programms.
Wenn ein Programm gekillt wird oder crasht, dann ist der Speicher sofort wieder frei.
Probier es doch aus. Schreib ein Programm das 200MB Speicher belegt und kille es. Ich fresse einen Besen wenn der Speicher nicht sofort wieder frei ist.
PuckPoltergeist
Grand Admiral Special
Dafür müßte das OS entsprechende garbage-collection Routinen realisieren, und das macht keines der mir bekannten Betriebssysteme.
H
hct
Guest
Das ist nicht richtig. Glaub mir doch einfach oder probier es aus und natürlich hat der Kernel eine garbage collection. Er weiss doch welcher Prozess welche Resourcen belegt und wenn der Prozess wegstirbt, dann werden die Resourcen frei gegeben.
Ich weiss nicht wo du dein Wissen über Betriebssysteme her hast aber ich würde diese Quelle überdenken.
Wenn du selbst kein Programm geschrieben kriegst, dann nimm halt das hier:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main() {
void *cp=(calloc( 130000000, 1 ));
if( ! cp )
printf("not enough mem\n");
printf("Kill me. Kill me now.\nkill -9 %d\n",getpid());
while(1)
sleep(10);
}
Das sollte ja wohl aus Beweis genügen. Probier das von mir aus auch mit Files und Sockets aus.
PuckPoltergeist
Grand Admiral Special
Das reicht nicht, weil der Speicher damit nicht belegt wird. Solange der alloziierte Speicher nicht wirklich beschrieben wird, wird er auch nicht belegt (kannst du mit free nachprüfen).
Nach deiner Aussage wären Speicherlecks unmöglich, da das OS am Ende immer aufräumt.
H
hct
Guest
Hast du das Programm ausprobiert? Natürlich belegt calloc den Speicher. Es schreibt ihn mit Nullen voll.
Denk mal über eins nach. Wenn der Speicher nicht mehr frei gegeben werden würde, dann könnte jeder scheiss User jedes Linux crashen auf dem er eingeloogt ist. Er kann ja in Null Komma nix den gesamten Speicher aufzehren.
Speicherlecks sind natürlich nicht unmöglich aber sie existieren NUR während der Laufzeit eines Programms.
Langsam glaube ich du willst mich verarschen. So uneinsichtig kann man doch gar nicht sein. Darum End of discussion.
DarkSpirit
Cadet
- Mitglied seit
- 14.04.2004
- Beiträge
- 43
- Renomée
- 0
Quellen? Ich halte das einfach für falsch, sorry
Aus einer C-Referenz aus meinem Bücherschrank: "Dynamisch allokierter Speicherplatz muss entweder vom Programmierer explizit freigegeben werden oder bleibt bis zum Programmende reserviert."
Der Kernel dürfte bei der Handhabung des SIGKILL genauso reagieren wie beim normalen Beenden des Programms (ich sage bewusst "Kernel", das Programm selbst geht mit beidem natürlich anders um bzw. eben mit erstgenanntem überhaupt nicht).
PuckPoltergeist
Grand Admiral Special
Ich war noch bei malloc, deshalb der Irrtum.
Ok, du hast recht, der Speicher wird wieder frei gegeben. Das hat aber nix mit deinem Vergleich zu tun. Das System kann trotzdem noch jeder User crashen. Er kann ja einfach so viel Speicher anfordern, das nix mehr übrig bleibt. Das ist als kein Kriterium.
Nein, ich war wirklich auf dem Holzweg.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
H
hct
Guest
Wenn der Admin keine Ahnung hat vielleicht. Sonst nicht.
PuckPoltergeist
Grand Admiral Special
Wie will er denn verhindern, dass ein Programm den gesamten Speicher aufbraucht?
Ähnliche Themen
