今天遇到一个集群重启后，gcware正常，gcluster和gnode都显示CLOSE状态，经过排查，是因为集群依赖的操作系统用户gbase被意外重建了，导致安装目录的属主不正确，没有权限访问导致。
目录导航
错误现象
gcware正常，gcluster和gnode都显示CLOSE状态
排查过程
重点是gnode服务是不依赖其它服务的，而gcluster依赖gcware。因为gcware部署在根目录下，而gcluster，gnode目录一般都是默认都是单独挂载一块大容量磁盘的，所有先怀疑是文件系统没有挂载，导致服务找不到可执行文件。
检查挂载情况
df -h检查，发现挂载正常，/opt/gbase存在。既然磁盘挂载正常，那检查一下服务的启动日志system.log看什么报错信息。
检查启动日志
查看gnode服务system.log日志，发现 No Space left on device和No such file or directory的报错信息，怀疑磁盘空间满了。结合前面的df -h容量没满，后续检查inode是否满了。
检查inode
df -i 发现inode没有满，但为啥会出现空间不足，以及文件不存在的报错呢？ 日志里没有更多信息。后面尝试重启服务，再次查看报错日志是否有变动。
尝试重启服务
用户反馈日志无任何变动，并没有新的日志生成。后续单独启动服务进程，查看报错信息。
单独启动服务进程
却换到gbase用户(su - gbase),然后运行gbased进程，发现报错信息
can't create test file，和 Can't change dir to XXX (Errcode: 13)
查看操作系统报错码。errcode 13对应Permission denied， 拒绝访问，怀疑权限有问题。
查看文件权限
发现数据库安装目录的宿主丢失，变成了1034，而用户组还是gbase。
至此确诊，是权限问题导致。猜测是操作系统用户gbase被重建了，导致原来属于gbase的目录变成了uid(1034)。
解决方案
通过 chown -R gbase:gbase XXX 将数据库目录和文件修改成正确的属主。 重启服务后集群恢复正常。
总结
操作系统gbase用户是数据库的安装和运行用户，程序是以gbase用户启动和运行，而一旦操作系统用户gbase被重建，将导致属主变动，目录无法访问（写入)，导致启动失败。