Każdemu zdarza się popełniać błędy, nawet programistom o czym można przekonać się przeglądając listy z dziurami zabezpieczeń, np. Secunia Advisories. Błędy bezpieczeństwa to nie jedyny problem, z którym administrator musi się zmagać w codziennej pracy.

W ostatnim czasie na kilku produkcyjnych maszynach zaczęły się problemy z obciążeniem oraz błędami systemu plików, które skutkowały automatycznym przemontowaniem partycji w trybie tylko do odczytu co następnie prowadziło do destabilizacji maszyny przez procesy, które chciały coś na tej partycji zapisać. Rzut okiem na logi serwera oraz przeszukanie redhatowego bugtraqua i oto mamy punkty zaczepienia.

Postępowanie w takich sytuacjach jest bardzo proste:
1. Należy zachować spokój, gdyż nieprzemyślane działanie może przynieść więcej szkody niż pożytku
2. Przyjrzeć się dokładnie logom serwera, w tym przypadku w logach powtarzają się wpisy:
Jul 8 10:16:14 erwin kernel: EXT3-fs error (device md4): ext3_lookup:
unlinked inode 99189142 in dir #99188744
Jul 8 10:16:14 erwin kernel: Aborting journal on device md4.
Jul 8 10:16:14 erwin kernel: __journal_remove_journal_head: freeing
b_committed_data
Jul 8 10:16:14 erwin last message repeated 2 times
Jul 8 10:16:14 erwin kernel: ext3_abort called.
Jul 8 10:16:14 erwin kernel: EXT3-fs error (device md4):
ext3_journal_start_sb: Detected aborted journal
Jul 8 10:16:14 erwin kernel: Remounting filesystem read-only
3. Jak widać problem występuje z journalem systemu plików (jest on uszkodzony), więc należy go przywrócić:
- uruchamiamy system w single mode (należy dodać parametr single do wiersza parametrów kernela w bootloaderze
- należy odmontować uszkodzoną partycję, np. umount /dev/md4
- usuwamy uszkodzony journal: tune2fs -O ^has_journal /dev/md4
- sprawdzamy system plików co może trochę potrwać: e2fsck -fy /dev/md4
- zakładamy nowy journal: tune2sf -j /dev/md4
- ponownie sprawdzamy system plików: fsck -y /dev/md4
- reboot
4. Jeśli wszystko przebiegło bez problemów to możemy się cieszyć z kolejnego rozwiązanego problemu.