The problem is as follows:
But it can be started normally through ./dmserver path=xxx/dm.ini
Check the log and find that there is a generated log: /home/dmdba/dmdbms/log/dm_unknown_yyyymm.log. The log content is as follows:
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
After inspection, there is indeed no such libpmen file. At first I thought it was a problem with the installation package I used, but later I found that the reason for the problem was a permission problem : jump to the installation directory /home/dmdba/dmdbms/, and then ls: the file group in the entire installation directory should be in a general linux environment: dmdma dinstall
You can see that the attribute group of the data directory is root, not dmdba, by command: chown dmdba:dinstall -R ./*Change the attribute group of the entire folder:
It can be seen that after changing the group of the data directory to dmdba dinstall , the service can be started normally.
The reason for such a problem is that /home/dmdba/dmdbms/data/DAMENG/dm.ini is specified when the database instance directory needs to be specified when initializing the database instance, and the ./dminit tool is run by the root user. Although the tool The initialization is successful, but the data directory is generated by the root user, leaving permission issues:
- In the general linux environment, when dealing with database-related commands, it is best to operate after su - dmdba.