Bekijk Volledige Versie : /home gaat in readonly
Op een server van mij gaat na een tijdje /home in read only
Ik heb een fsck check gedaan en die geeft geen fouten..
Wie kan me zeggen wat ik nog meer kan doen?
Hieronder een stukje uit de log file:
Dec 8 09:50:26 srv02 smartd[4051]: Configuration file /etc/smartd.conf has fatal syntax errors.
Dec 8 09:50:26 srv02 smartd[4051]: Monitoring 0 ATA and 0 SCSI devices
Dec 8 09:50:26 srv02 smartd[4053]: smartd has fork()ed into background mode. New PID=4053.
Dec 8 09:53:07 srv02 kernel: EXT3-fs error (device sda8): ext3_free_blocks_sb:
bit already cleared for block 24202726
Dec 8 09:53:07 srv02 kernel: Aborting journal on device sda8.
Dec 8 09:53:07 srv02 kernel: EXT3-fs error (device sda8) in ext3_free_blocks_sb: Journal has aborted
Afgelopen weekend hebben wij hetzelfde gehad op een Dell server. Zomaar uit het niets in RO filesystem. Geen hardware errors, en geen foutmeldingen. Wat de reden ervan is, zijn wij ook nog aan het uitzoeken.
Ik lees dingen over de sas6i/r raid kaarten, dat die vage problemen leveren, maar zekerheid kan ik daar niet over geven nog :(
Ik ben bezig met awstats, omdat ik alleen nog webalizer wil ben ik de mappen /awstats aan het verwijderen.
Zodra ik bij een bepaalde map van een user kom en als ik daar de map /awstats wil verwijderen gaat die op read only
Er zit een 3ware 8006-2LP raid controller in, ook hier zie ik geen fouten..
Ik kom er niet uit..
Nu dacht ik ik verwijder de user waar die fout zit en maak hem opnieuw aan.
Bij het verwijderen gaat de map /home weer op read only
Wak kan ik het best doen?
Heb je wel de goede partitie gechecked, ik zie dat ext3 fouten geeft. Je zou hem eigenlijk moeten unmounten en dan goed checken.
Ook zou je met smarttools kunnen kijken of er fouten op de harddisk zijn geconstateerd
nieuwe disk/partitie gaan gebruiken?
Het kan ook je (verouderde) kernel zijn, zie: http://rhn.redhat.com/errata/RHSA-2009-0331.html
* a misplaced memory barrier at unlock_buffer() could lead to a concurrent
h_refcounter update which produced a reference counter leak and, later, a
double free in ext3_xattr_release_block(). Consequent to the double free,
ext3 reported an error
ext3_free_blocks_sb: bit already cleared for block [block number]
and mounted itself as read-only. With this update, the memory barrier is
now placed before the buffer head lock bit, forcing the write order and
preventing the double free. (BZ#476533)
Ik heb dit gedaan:
umount: /home: device is busy (zelde als met umount /dev/sda8)
-
Met umount -f -l /dev/sda8 gaat het goed
-
Nu met het volgende gaat het mis:
# fsck /home
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
fsck.ext3: Device or resource busy while trying to open /dev/sda8
Filesystem mounted or opened exclusively by another program?
met lsof kan je zien welke bestanden er nog open staan en dan moet je die services stoppen, netzolang tot je hem wel kan mounten, anders ff met een bootcd starten en dan checken
Heb eerst alles gestopt, daarna umount /home
fsck /home
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/home: clean, 515771/27885568 files, 15283836/27868750 blocks
Hij vind geen fouten..
De kernel is: 2.6.18-194.11.1.el5 (SMP)
Het probleem is nog niet opgelost.. bij het verwijderen van de user gaat die in read only
Bij de rest gaat het wel goed.
die kernel is redelijk oud, heb je mijn post gezien over dat kernel probleem?
die kernel is redelijk oud, heb je mijn post gezien over dat kernel probleem?
Ik ga hem nu upgraden.. over 10 min. weet ik of het daar aan ligt.
Met de laatste kernel 2.6.18-194.26.1.el5 (SMP) hetzelfde probleem.
Hij vliegt weer op read only als ik die user wil deleten.
Lijkt me dan toch een probleem op de hd zelf. Misschien eens restarten en een fsck doen?
Of heb je die mogelijkheid niet?
Lijkt me dan toch een probleem op de hd zelf. Misschien eens restarten en een fsck doen?
Of heb je die mogelijkheid niet?
Vandaag heb ik hem wel 10x opnieuw opgestart en fsck geeft aan dat die clean is.
De laatste redmiddel is /home opnieuw te formateren, of heeft iemand anders nog een idee?
Heb eerst alles gestopt, daarna umount /home
fsck /home
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/home: clean, 515771/27885568 files, 15283836/27868750 blocks
Hij vind geen fouten..
De kernel is: 2.6.18-194.11.1.el5 (SMP)
Het probleem is nog niet opgelost.. bij het verwijderen van de user gaat die in read only
Bij de rest gaat het wel goed.
Maar heeft fsck wel gechecked ?
Als hij alleen maar naar de filesystem-clean vlag in het superblock gekeken heeft , zegt dat niks.
Dat is de default, voor een clean filesystem. Pas na een x-aantal dagen of y aantal mounts (instelbaar met tune2fs, zichtbaar met dumpe2fs) wordt een filesystem alsnog gechecked ook wanneer het clean is.
Doe eens : fsck -f -V /dev/sda8
(-f : force, -V : verbose)
Hoe doe je de fsck: via single mode of een rescue cd ?
Laatst voor een klant soortgelijke problemen gehad ook met een 3ware 8006-2 en 2 wdc re schijven de controller en array waren allen goed gaven geen smart meldingen
zowel via hdparm als 3dm tool (centos machine).
Echter na rescue mode opstarten en de filesystem gecontroleerd kwamen er toch badsectors naar boven deze waren gefixed heb daarna nieuwe schijf erin gedaan zodat hij kon rebuilden paar uur later klaar de schijven allebei geswapped.
Zodat de klant voorzien was van een nieuwe set schijven had in raid 1.
Daarna heb ik om de fout op te sporen de oude defecte schijven los gecontroleerd met een tooltje van western digital om iig zeker te weten dat het niet software gerelateerd was.
Hierbij bleek dat er meerdere bad blocks waren welke niet zichtbaar waren voor je os direct en ook niet door de 3dm tool maar wel door het programma van western digital
echter de smart status bleef goed dus het probleem lag gewoon aan de schijven.
Doe eens : fsck -f -V /dev/sda8
(-f : force, -V : verbose)
Heb ik nu gedaan.. zie de uitkomst:
fsck -f -V /dev/sda8
fsck 1.39 (29-May-2006)
[/sbin/fsck.ext3 (1) -- /home] fsck.ext3 -f /dev/sda8
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -24202470 +24202726
Fix<y>? yes
Free blocks count wrong for group #174 (26257, counted=26256).
Fix<y>? yes
Free blocks count wrong for group #230 (255, counted=250).
Fix<y>? yes
Free blocks count wrong for group #233 (178, counted=176).
Fix<y>? yes
Free blocks count wrong for group #404 (193, counted=194).
Fix<y>? yes
Free blocks count wrong for group #673 (2558, counted=2548).
Free blocks count wrong for group #738 (30778, counted=29804).
Fix<y>? yes
Free blocks count wrong for group #739 (31720, counted=31664).
Fix<y>? yes
Free blocks count wrong (12702885, counted=12701838).
Fix<y>? yes
Free inodes count wrong for group #174 (32747, counted=32746).
Fix<y>? yes
Free inodes count wrong for group #230 (32526, counted=32518).
Fix<y>? yes
Free inodes count wrong for group #673 (24808, counted=24807).
Fix<y>? yes
Free inodes count wrong for group #738 (32564, counted=32422).
Fix<y>? yes
Directories count wrong for group #738 (5, counted=4).
Fix<y>? yes
Free inodes count wrong (27390589, counted=27390437).
Fix<y>? yes
/home: ***** FILE SYSTEM WAS MODIFIED *****
/home: 495131/27885568 files (6.9% non-contiguous), 15166912/27868750 blocks
Hopelijk gaat het nu weer goed, de laatste check was ook al een jaar geleden.
Vandaag heb ik hem wel 10x opnieuw opgestart en fsck geeft aan dat die clean is.
Ik vergat hierbij te melden dat ik bedoelde om het in single mode dan te checken ;)
Maar ik zie dat er inmiddels wat troubles gefixed zijn, dus hopen dat het nu goed gaat.
Iedereen bedankt voor het helpen!
De map waardoor /home in read-only ging kon nu verwijderd worden zonder problemen.
Achteraf had ik dit in 5 minuten kunnen fixen, dus alweer wat geleerd :)
-
ichosting ik heb het niet in single mode gedaan, de map /home is een aparte partition en dan heeft dat geen nut volgens mij omdat de fout in /home zat.
Zo te zien zijn de hdd's verder goed, maar ik zal ze vanaf nu extra gaan monitoren voor de zekerheid.
-
ichosting ik heb het niet in single mode gedaan, de map /home is een aparte partition en dan heeft dat geen nut volgens mij omdat de fout in /home zat.
Zo te zien zijn de hdd's verder goed, maar ik zal ze vanaf nu extra gaan monitoren voor de zekerheid.
Maar /home wordt wel op een hd aangemaakt die mogelijk corrupt is. Dus een fsck in single mode levert vaak ook helderheid op.
Maar het is opgelost nu, en dat is het belangrijkste toch ;)