[ ntop ] daemon stopt na ongeveer 1 dag

[Verwijderd]

Ik heb ntop (v.2.0.0) draaien op een debian woody server in daemon mode (poort 3000, met webfrontend dus).
Probleem is nu dat hij na ongeveer een dag plots stopt en ik de daemon moet herstarten.
Ik vind hierover niks terug in de logs op het eerste zicht.
/var/log/ntop/ is leeg en in /var/log/messages zie ik enkel:

"device eth0 left promiscuous mode"

maar dat is eerder een gevolg van dat ntop niet meer draait dan omgekeerd, niet?

[Wilke]

Klopt, dat is idd meer een gevolg dan een oorzaak

Overigens is ntop een vrij link progje om te draaien als ik bugtraq moet geloven, het schijnt echt belabberd geprogrammeerd te zijn en daardoor gevoelig voor allerlei buffer overflows. Aangezien het als root draait, nou ja, de rest kun je zelf bedenken...

Heb het persoonlijk niet ondervonden, maar misschien moet je eens uitzoeken hoe het daar mee zit.

(Verder geen suggesties voor de oplossing van je probleem, helaas)

[deadinspace]

Staat er iets boeiends in /var/log/daemon.log ?
Kun je ntop ook zo starten dat hij niet naar de achtergrond gaat (debug mode misschien) ?

[Verwijderd]

in /var/log/daemon.log staat niets
ik zal ntop is in foreground laten draaien en kijken of dat iets geeft, maar dat geeft nogal veel output en als het dan weer 1,5 dag duurt...

[deadinspace]

Gewoon in screen draaien dan... Dan hoef je er pas weer naar te kijken op het moment dat het fout gaat.

[Verwijderd]

kan ik dat dan bekijken als ik weer inlog (ssh kickt mij eruit na een bepaalde tijd) ?
Ik had om te proberen (had niet veel tijd) "screen ntop -d" gedaan en dan via ctrl-a H screen laten loggen nr een bestand.
Ondertussen is ntop weer gecrasht maar die logfile is niet aangemaakt.
Wat is nu juist eigenlijk de bedoeling van screen? Een soort van console-window-manager?
En hoe kan screen mij helpen?
Ik denk dat ik daar nog eens grondig naar moet zien als ik meer tijd heb, iig al bedankt vr de reacties

[deadinspace]

Ehmm, crash course screen:

Mogelijk heb je al screens draaien door wat je hebt gedaan, deze kun je het beste even killen: killall screen (mogelijk gaat je ntop er ook weer aan hierdoor).
Start screen zonder argumenten.
Druk op spatie.
Start ntop.
Doe ctrl-a, d.
Screen terugkrijgen door "screen -r" te typen.

Voor meer informatie: ctrl-a, h in screen, en/of "man screen".

[Verwijderd]

ok , het is gelukt met screen (bedankt vr de crash course )
dit is de output :

code:

...
15/Oct/2002 17:32:50 Initializing plugins (if any)...
15/Oct/2002 17:32:50 Waiting for HTTP connections on port 3000...
15/Oct/2002 17:32:50 Sniffying...
15/Oct/2002 17:32:50 Started thread (9226) for network packet sniffing on eth0.
15/Oct/2002 17:32:58 Extending hash: [old=32, new=48]
15/Oct/2002 17:33:12 Extending TCP hash [new size: 64]
15/Oct/2002 17:33:17 Extending TCP hash [new size: 128]
15/Oct/2002 17:33:21 Extending hash: [old=48, new=72]
15/Oct/2002 17:34:10 Extending TCP hash [new size: 256]
15/Oct/2002 17:35:59 Extending hash: [old=72, new=108]
15/Oct/2002 17:48:23 Extending hash: [old=108, new=162]
15/Oct/2002 18:24:23 Extending TCP hash [new size: 512]
15/Oct/2002 18:55:34 Extending hash: [old=162, new=242]
15/Oct/2002 20:59:58 Extending TCP hash [new size: 1024]
16/Oct/2002 08:19:21 Extending hash: [old=242, new=362]
16/Oct/2002 11:08:16 Extending hash: [old=362, new=542]
16/Oct/2002 12:03:58 IPv6 is unsupported: assuming raw.
Segmentation fault

Niet echt veel nuttige informatie, volgens mij.
Is kijken of ntop missch iets verboser kan zijn.

[deadinspace]

Mja, segfault... Is op zich vrij duidelijk: ntop crasht, waarschijnlijk door een bug in ntop.
Staat ntop ook open voor de buitenwereld (dus meestal: voor je netwerkkaart die aan internet hangt) ? Zo ja, dan is het verstandig dat te blokkeren. Het is mogelijk dat mensen connecten op jouw ntop, en misschien proberen hem te exploiten. Dat zou die segvs kunnen veroorzaken.