分区变为只读的处理

发表于 分类于 阅读次数： 阅读时长 ≈ 11 分钟

这是一个独立邮件系统客户服务器的问题，抽点时间记录一下处理过程，要不时间久了又要忘了。话说时间挤挤总会有的^_^

问题：
登陆web提示系统错误。无法发送邮件，提示邮件发送失败

分析：
向客户要来服务器ip及root密码，登陆查看。

1、查看webmail日志，错误关键字：存储邮件异常，只读文件系统。如下：
1567496235290

2、测试在在mail分区下创建文件，无法成功创建，提示只读文件系统：

1
2
[root@localhost mail]# touch abc
touch: 无法触碰 “abc”: 只读文件系统

3、查看系统日志信息/var/log/messages：

1
2
3
4
5
6
7
8
9
10
11
[root@localhost ~]# tail -100 /var/log/messages | grep kernel
Jan  6 11:15:35 localhost kernel: EXT3-fs error (device sda2): htree_dirblock_to_tree: bad entry in directory #40534515: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Jan  6 11:29:17 localhost kernel: ext3_abort called.
Jan  6 11:29:17 localhost kernel: EXT3-fs error (device sda2): ext3_put_super: Couldn't clean up the journal
Jan  6 11:30:20 localhost kernel: kjournald starting.  Commit interval 5 seconds
Jan  6 11:30:20 localhost kernel: EXT3 FS on sda2, internal journalJan  6 11:30:20 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jan  6 11:31:02 localhost kernel: clamd[27699]: segfault at 0000000000000060 rip 00002ae03828c71b rsp 00007fff8f5ca6f0 error 4
Jan  6 13:29:45 localhost kernel: EXT3-fs error (device sda2): htree_dirblock_to_tree: bad entry in directory #40534515: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Jan  6 13:29:45 localhost kernel: Aborting journal on device sda2.
Jan  6 13:29:46 localhost kernel: ext3_abort called.Jan  6 13:29:46 localhost kernel: EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted journal
Jan  6 13:29:46 localhost kernel: Remounting filesystem read-only

可以看出这是由于文件系统错误，内核将文件系统重新挂载为只读模式

处理：修复mail分区
1、先卸下mail分区

1
2
3
[root@localhost tmp]# umount /mail/
umount: /mail: device is busy
umount: /mail: device is busy

无法卸下，有程序在访问mail分区

2、查看是什么程序在访问mail分区

1
2
3
4
5
[root@localhost tmp]# fuser -m -v /dev/sda2
                     USER        PID ACCESS COMMAND
/dev/sda2:             root      26947 ..c.. bash
                     root      27215 ..c.. tail
                     root      27216 ..c.. grep

3、将访问mail分区的程序kill掉

1
2
[root@localhost tmp]# fuser -m -k /dev/sda2
/dev/sda2:           26947c

4、重新卸下mail分区

1
2
3
4
5
6
[root@localhost tmp]# umount /mail/
[root@localhost ~]# df
文件系统               1K-块        已用     可用 已用% 挂载点
/dev/sda3             29753588   8215320  20002456  30% /
/dev/sda1              7936256    155460   7371144   3% /boot
tmpfs                  2017004         0   2017004   0% /dev/shm

这次没有提示错误了，使用df查看mail分区已被卸下

5、修复分区

1
2
[root@localhost ~]# screen -S fsck           在sceen下修复
[root@localhost ~]# fsck -Cy /dev/sad2   		修复分区

修复完成后再测试在mail分区下创建文件

1
[root@localhost mail]# mkdir test

没有提示错误，成功创建
将之前创建的文件夹删除

1
[root@localhost mail]# rmdir test/

6、重启邮件系统和webmail服务

最后一步查看webmail日志，日志显示正常。登陆web端测试发送邮件，提示发送邮件成功，问题解决。

整个过程涉及到几个命令：mount，fuser，screen，fsck。有时间再整下这几个命令的用法。

=========================================================

2013-05-29
今天又碰到一例只读文件系统。按照上面的流程操作修复，但执行修复命令（fsck -Cy /dev/sad2）后，一瞬间就好了，提示文件系统是clean状态：

1
2
3
4
[root@localhost ~]# fsck -y /dev/sda1
e2fsck 1.39 (29-May-2006)
/: recovering journal
/: clean, 2226424/229310464 files, 155758033/229291720 blocks

重新挂载，恢复读写。但一会后又只读。
尝试使用-f参数强制检查修复文件系统，检查出不少错误，完后挂载，测试一段时间，没有再出现问题。
另外，使用-f参数强制检查前，最好先备份下数据，防止数据丢失。

1
2
-f      Force checking of file systems, even when they are marked clean
            (for file systems that support this).
相关文章