[CentOS] locate probleem

[Pin0]

Omdat ik wilde weten waar een bepaald bestand stond wilde ik locate gebruiken, omdat de locate database al een tijdje niet was geupdate:

[root@localhost]# locate -u
Segmentation fault

Geen idee wat dat is dus nogmaals proberen

[root@localhost]# locate -u

Met als gevolg een hangende shell (nb na locate -v -u stopt ie ook gewoon met het weergeven van de bestanden die hij indexeerd)
Na wat gezoek kom ik er achter dat de Segmentation fault te maken heeft met een proces wat geheugen probeert te benaderen wat niet voor hem is bedoeld of zo... geen idee wat nu te doen.

Opnieuw ingelogd:
[root@localhost]# ps -aux
met daarin de volgende regel:
root 1991 0.0 0.4 2936 592 ? D 11:41 0:00 locate -u
Die moet er dus uit, we willen het wel een beetje schoon houden allemaal.
Dus:
[root@localhost]# kill 1991
[root@localhost]# kill -9 1991

Het mag allebij niet baten.

Wat ik mij dus afvraag is:
Weet iemand waar die Segmentation fault vandaan komt. (kan dit met rechten te maken hebben? chown, chmod, chcon etc)?
Hoe kill ik dat proces?
Waar staat die D voor? (in root 1991 0.0 0.4 2936 592 ? D 11:41 0:00 locate -u)

offtopic:
Ik heb gezocht maar geen Segmentation fault in combinatie met locate

[VisionMaster]

Ik update mijn locate altijd via 'updatedb'. Ik geloof dat dat tooltje er speciaal voor bedoeld was.

Die segfault ... dat is gewoon een software bug. Nogal gaar dat dat gebeurt.
Welke CentOS release gebruik jij. Hier op mijn werk (en ook thuis) zijn wij een veel vuldig CentOS gebruiker.

trouwens als je in de 'man ps' pagina kijkt, dan zal je zien 'D' staat voor uninterruptable sleep (usually I/O).
Wat je daar nu aan hebt... ik heb geen idee
Wachten is misschien een oplossing ...

Als het ECHT niet te verwijderen valt is reboot natuurlijk nog een 'last-resort'

[ Voor 35% gewijzigd door VisionMaster op 19-07-2005 12:29 ]

[Pin0]

updatedb werkt idd naar behoren en een stuk sneller dan locate -u
Om de locate -u als proces te verwijderen moest ik opnieuw opstarten...
Ook toen ik ls -R deed liep dat proces ook vast... vaag

Wel raar van die segfault...

[VisionMaster]

segfault zijn in de regel memory problemen, zoals niet voldoende gealloceerd geheugen gebruiken of een free() doen waar het niet hoort of (meer) mag.

Puur een software bug. Ik weet zelf niet beter dan dat ik 'updatedb' gebruik hiervoor.

[deadinspace]

Pin0 schreef op dinsdag 19 juli 2005 @ 12:22:
Omdat ik wilde weten waar een bepaald bestand stond wilde ik locate gebruiken, omdat de locate database al een tijdje niet was geupdate:

[root@localhost]# locate -u
Segmentation fault

Geen idee wat dat is dus nogmaals proberen

[root@localhost]# locate -u

Met als gevolg een hangende shell (nb na locate -v -u stopt ie ook gewoon met het weergeven van de bestanden die hij indexeerd)
Na wat gezoek kom ik er achter dat de Segmentation fault te maken heeft met een proces wat geheugen probeert te benaderen wat niet voor hem is bedoeld of zo... geen idee wat nu te doen.

Opnieuw ingelogd:
[root@localhost]# ps -aux
met daarin de volgende regel:
root 1991 0.0 0.4 2936 592 ? D 11:41 0:00 locate -u

Pin0 schreef op woensdag 20 juli 2005 @ 11:56:
Ook toen ik ls -R deed liep dat proces ook vast... vaag

ls -R waar? Kun je wel gewoon naar de 'vastlopende' plek gaan en een beetje door de dirs daar browsen en ls doen?

Kijk ook eens in /var/log/messages of je foutmeldingen ziet mbt je harddisk. Door de aard van deze fouten vermoed ik hardware falen (HD of misschien geheugen/CPU), een verneukt filesystem of een kernel bug.