:strip_exif()/u/3806/vimico.gif?f=community)
There is no adequate defense, except stupidity, against the impact of a new idea.
ik heb een zeer klein aantal processen draaien, nauwelijks bestanden geopend staan, geen remote filesystems gemount, een serverload van onder de 0.10. het gaat hier om een servertje dat voornamelijk als router draait, en waar een aantal mp3's en films op staat. ik heb de server al meerdere malen gereboot maar het probleem blijft. erg jammer. 
zou het kunnen helpen als ik de huidige filedatabase leeghaal? zo ja: hoe doe ik dat?
zou het kunnen helpen als ik de huidige filedatabase leeghaal? zo ja: hoe doe ik dat?
There is no adequate defense, except stupidity, against the impact of a new idea.
:strip_exif()/u/42289/adologo.gif?f=community)
:strip_icc():strip_exif()/u/10190/debian2.jpg?f=community)
Als dat zo was, dan zou ik niet verwachten dat hij nog wel andere dingen kon doen...het is niet alsof updatedb nu zo ontzettend veel geheugen vreet of idioot veel nieuwe processen start
. Je oplossing met strace lijkt me beter - als daar niets uit komt dan is het waarschijnlijk een hardwareprobleem, of een worm/rootkit/whatever die niet door rootkit gedetecteerd wordt.
Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.
/u/47968/avatargot.png?f=community){kind=avatar}
Uit regel 78 van je logs haal ik dat je je /usr/bin/updatedb ooit vervangen hebt door iets anders . In de 'echte' updatedb staat namelijk niet op de tweede regel iets als "even updatedb uitvoeren", in ieder geval niet in de mijne . Waarschijnlijk roept dat script zichzelf steeds weer aan of zo, dat is ook wel in de strace-uitvoer terug te vinden maar dat lijkt me niet zo heel relevant - dat zie je in het script zelf veel sneller.
. In de 'echte' updatedb staat namelijk niet op de tweede regel iets als "even updatedb uitvoeren", in ieder geval niet in de mijne . Waarschijnlijk roept dat script zichzelf steeds weer aan of zo, dat is ook wel in de strace-uitvoer terug te vinden maar dat lijkt me niet zo heel relevant - dat zie je in het script zelf veel sneller.
Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.
tja, ik pruts wel vaker wat. Ik heb dit vroeger eens in de crondeamon gezet, zodat iedere nacht updatedb uitgevoerd zou worden. beetje slordig dus:
Uit regel 78 van je logs haal ik dat je je /usr/bin/updatedb ooit vervangen hebt door iets anders
ik heb hem nu weggehaald en het oude updatedb dingetje weer teruggezet. nu werkt het gewoon weer. bedankt hiervoor. ik heb nu in ieder geval een goede kernel draaien
There is no adequate defense, except stupidity, against the impact of a new idea.
:strip_icc():strip_exif()/u/17788/Anonymouse.jpg?f=community)
Run eerst even een filesystem check op (al) je schijf(/ven) die gemount zijn op het moment dat je updatedb gebruikt.
Blijkbaar raakt hij in een niet af te breken lus.
een fork zorgt er voor dat een zelfde applicatie als "child process" verder gaat runnen.
Vermoedelijk bij updatedb zet hij een fork op PER DIRECTORY.
Effect als je een link van een dir naar zichzelf hebt (eigenlijk een looped link) dat hij eeuwig door wil gaan.
3 mogelijke redenen voor het foutgaan dus :
- updatedb heeft een techniek die dit tegengaat (hij volgt simpelweg geen symlinks); staat er echter een hardlink geloopt is de kans groot dat hij deze wel volgt.
- Mogelijk is er een Filesystem fout waardoor er een looped link is.
(een symlink staat dan bijvoorbeeld als ECHTE dir aangegeven)
fschk moet dit kunnen detecteren.
- Je hebt iets van 8 MB intern geheugen
Blijkbaar raakt hij in een niet af te breken lus.
een fork zorgt er voor dat een zelfde applicatie als "child process" verder gaat runnen.
Vermoedelijk bij updatedb zet hij een fork op PER DIRECTORY.
Effect als je een link van een dir naar zichzelf hebt (eigenlijk een looped link) dat hij eeuwig door wil gaan.
3 mogelijke redenen voor het foutgaan dus :
- updatedb heeft een techniek die dit tegengaat (hij volgt simpelweg geen symlinks); staat er echter een hardlink geloopt is de kans groot dat hij deze wel volgt.
- Mogelijk is er een Filesystem fout waardoor er een looped link is.
(een symlink staat dan bijvoorbeeld als ECHTE dir aangegeven)
fschk moet dit kunnen detecteren.
- Je hebt iets van 8 MB intern geheugen
-=@@D=- Macbook Pro 16"
Pagina: 1