问题现象如下:

但是通过./dmserver path=xxx/dm.ini又能正常启动
查看日志发现有生成日志:/home/dmdba/dmdbms/log/ dm_unknown_yyyymm.log。 日志内容如下:
fail to load libpmem.so, libpmem.so: cannot open shared object file: No such file or directory
2023-05-19 19:16:17.546 [INFO] database P0000083979 T0000000000000083979 Fail to load libpmem
经过查验确实没有这个libpmen文件。 开始以为是使用的安装包有问题,后来发现问题原因是权限问题:跳转安装目录/home/dmdba/dmdbms/下,然后ls: 整个安装目录下文件属组在通用linux环境下都应该是:dmdma dinstall

可以看到data目录的属组是root,而不是dmdba, 通过命令:chown dmdba:dinstall -R ./* 更改整个文件夹的属组:

可以看到当把data目录属组改为dmdba dinstall之后,服务就可以正常启动了。
出现这样的问题原因是因为在初始化数据库实例的时候需要指定数据库实例目录时指定了/home/dmdba/dmdbms/data/DAMENG/dm.ini,运行./dminit 工具是通过root用户进行的,虽然工具初始化成功,但是却是通过root用户生成了data目录,遗留了权限问题:

- 在通用linux环境下,处理数据库的相关命令时,最好是su - dmdba之后再进行操作。
文章描述了一种数据库服务启动失败的问题,由于初始化数据库实例时使用了root用户,导致data目录权限属于root而非dmdba。修复方法是通过chown命令更改变目录的属组。确保在执行数据库相关操作时使用正确的用户(如dmdba)可以避免类似问题。

被折叠的 条评论
为什么被折叠?



