Postgres启动时遇到只读文件系统的错误
Postgres启动时遇到只读文件系统的错误
September 20, 2020
问题与解决方法
公司内部私有云由于断电，机器没有正常关机，结果导致 Postgres 服务器启动时，报错
2020-09-09 07:22:15.296 UTC [3876] FATAL: could not remove old lock file "postmaster.pid": Read-only file system
2020-09-09 07:22:15.296 UTC [3876] HINT: The file seems accidentally left over, but it could not be removed. Please remove the file by hand and try again.
pg_ctl: could not start server尝试执行下面命令去重新挂载磁盘目录
mount -o remount -w /var/lib/postgresql/但是报错
mount: /dev/vdb is write-protected but explicit `-w' flag given尝试另外一个命令
umount /dev/vdb但是还是报错
umount: /var/lib/postgresql: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)这样的话， 看上去由于系统没有正常关机，导致虚拟磁盘出现文件系统错误。只能通过fsck手动修复。
由于上面出现提示设备忙，则可以用下面命令查看进程号
fuser -m /var/lib/postgresql
/var/lib/postgresql: 3760c修改命令参数后可以查看进程，同时杀掉进程
fuser -mk /var/lib/postgresql
/var/lib/postgresql: 3760c杀掉进程后，如果控制台中的ssh连接断开了，重连即可
接着，运行命令修复磁盘
fsck.ext3 -y /dev/vdb然后重新挂载设备
mount /dev/vdb /var/lib/postgresql/重启服务即可
service postgresql restart关于fsck
ext3的文件系统使用fsck.ext3，ext4文件系统使用fsck.etx4。/dev/vda3是系统/根分区。运行完毕后，reboot重启系统就恢复正常
fsck不仅可以对文件系统进行扫描，还能修正文件系统的一些问题。注意的是fsck扫描文件系统时一定要在单用户模式、修复模式或把设备umount后进行。建议在单用户模式下运行。如果扫描正常运行中的系统，会造成系统文件损坏。
文件系统扫描工具有fsck、fsck.ext2、fsck.ext3、fsck.ext4、fsck.msdos、fsck.cramfs、fsck.ext4dev、fsck.vfat。最好是根据不同的文件系统来调用不同的扫描工具，比如ext3的文件系统使用fsck.ext3，ext4文件系统使用fsck.ext4等。
参考：
最后更新于