1

I've been getting a lot of crashes on my remote dedicated server - after they occur (in all sorts of different processes) the server becomes unresponsive and I have to reboot it. They all look something like this:

Feb 18 08:23:37 plex kernel: [1070520.320473] postgres      D 00004b40     0  1381   1332 0x00000000
Feb 18 08:23:37 plex kernel: [1070520.320500] Call Trace:
Feb 18 08:23:37 plex kernel: [1070520.320509]  [<c0271951>] ? ext3_do_update_inode+0x1f1/0x360
Feb 18 08:23:37 plex kernel: [1070520.320515]  [<c04dbb5b>] lock_sock_nested+0x6b/0xa0
Feb 18 08:23:37 plex kernel: [1070520.320520]  [<c016fc70>] ? autoremove_wake_function+0x0/0x50
Feb 18 08:23:37 plex kernel: [1070520.320525]  [<c04e33bd>] skb_free_datagram_locked+0x1d/0x40

Because they all seem to involve ext3 inode update functions I've been trying to run fsck. I sudo touch /forcefsck but after the reboot the /var/log/fsck folder still only contains logs that are months old. I suspect something had changed about fsck in recent Ubuntus but I can't find any documentation.

Andrew Lancaster
  • 11
  • 1
  • 1
    I'd backup your data and recreate filesystem. Use badblocks to check for unreadable sectors. If kernel is crashing while accessing a filesystem I'd not trust it even after fsck. – Tometzky Feb 18 '12 at 11:14

1 Answers1

0

If this is the root filesystem you should try to run a live cd and try to fix the filesystem from there. The cd you used to install the server can be used for that.

Open up a new console (like alt-f2) then:

fsck -a /dev/device_of_the_root_filesystem

UPDATE

You can do that with a USB drive too, but I do not see an easy way to do it remotely.

cstamas
  • 6,607
  • 24
  • 42