I recently installed mariadb-server 10.1 by adding the following repository:
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
...all was well until we had a power failure and upon rebooting unixodbc was segfaulting. Once I did a yum undo, the mysql odbc driver was functional.
I traced it to the following:
[root@ec-ast yum.repos.d]# ldd /usr/lib64/libmyodbc5w.so | grep -iE "my|maria" libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18 (0x00007f3dfb34c000) You have new mail in /var/spool/mail/root [root@ec-ast yum.repos.d]# repoquery -l MariaDB-server MariaDB-client MariaDB-commo MariaDB-shared galera boost-program-options jemalloc rsync lsof | grep lib64 | grep libmysqlclient /usr/lib64/libmysqlclient.so /usr/lib64/libmysqlclient.so.18 /usr/lib64/libmysqlclient.so.18.0.0 /usr/lib64/libmysqlclient_r.so /usr/lib64/libmysqlclient_r.so.18 /usr/lib64/libmysqlclient_r.so.18.0.0
...notice the change in the path (/usr/lib64/mysql/).
I could reinstall mariadb-server, add a symlink and it would probably work, but I thought it would be better to post and hopefully the maintainer of whichever package (unixodbc, maria, mysql-connector...) should be addressed, could be alerted to this issue in the event that it could (or should) be fixed on a package level.
John
Am 30.10.2017 um 20:22 schrieb John Harragin:
I recently installed mariadb-server 10.1 by adding the following repository:
[ ... ]
I could reinstall mariadb-server, add a symlink and it would probably work, but I thought it would be better to post and hopefully the maintainer of whichever package (unixodbc, maria, mysql-connector...) should be addressed, could be alerted to this issue in the event that it could (or should) be fixed on a package level.
John
CentOS cannot fix packages from yum.mariadb.org.
But the cloud SIG has build newer mariadb packges:
https://cbs.centos.org/koji/packageinfo?packageID=434
You can install them via yum too by the cloud repo.
http://mirror.centos.org/centos-7/7/cloud/x86_64/openstack-ocata/common/
Alexander
Thanks for your input.
It occurred to me that it might just be my config file that needs to be changed along with a package installation. It was weird that it worked for days and I was under considerable pressure to get it going quickly (while I was on vacation) so I am returning to this a while later (with the problematic package no longer installed). I'll look at this tomorrow and see if this is a non-issue or not. For now, ignore it...
John
On Mon, Oct 30, 2017 at 4:19 PM, Alexander Dalloz ad+lists@uni-x.org wrote:
Am 30.10.2017 um 20:22 schrieb John Harragin:
I recently installed mariadb-server 10.1 by adding the following repository:
[ ... ]
I could reinstall mariadb-server, add a symlink and it would probably work,
but I thought it would be better to post and hopefully the maintainer of whichever package (unixodbc, maria, mysql-connector...) should be addressed, could be alerted to this issue in the event that it could (or should) be fixed on a package level.
John
CentOS cannot fix packages from yum.mariadb.org.
But the cloud SIG has build newer mariadb packges:
https://cbs.centos.org/koji/packageinfo?packageID=434
You can install them via yum too by the cloud repo.
http://mirror.centos.org/centos-7/7/cloud/x86_64/openstack-ocata/common/
Alexander
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/30/2017 12:22 PM, John Harragin wrote:
[root@ec-ast yum.repos.d]# ldd /usr/lib64/libmyodbc5w.so | grep -iE "my|maria" libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18 (0x00007f3dfb34c000) [root@ec-ast yum.repos.d]# repoquery -l MariaDB-server MariaDB-client MariaDB-commo MariaDB-shared galera boost-program-options jemalloc rsync lsof | grep lib64 | grep libmysqlclient /usr/lib64/libmysqlclient.so.18
If the MariaDB packages provide the library in /usr/lib64, what provides the lib in /usr/lib64/mysql? (It looks like you have a library conflict)
rpm -qf /usr/lib64/mysql/*
More than likely, you can resolve the problem by removing the package that provides the files in /usr/lib64/mysql/. However, as Alexander pointed out, this isn't a problem with the CentOS packages, and you're more likely to get useful information if you address this question to the vendor of the broken package.
Thanks for each of your inputs.
It was not a configuration issue as odbcinst.ini does not reference the mysql subdirectory.
Rather than use Alexander's url, I ran: yum -y install centos-release-openstack-ocata yum -y install mariadb-server ...the cloud repository provides the properly pathed file.
# repoquery -l mariadb-server mariadb-libs | grep lib64 | grep libmysqlclient /usr/lib64/mysql/libmysqlclient.so.18 /usr/lib64/mysql/libmysqlclient.so.18.0.0
I installed this and isql was crashing. But (unlike the mariadb.com repository,) is did install: /usr/lib64/mysql/libmysqlclient.so ...in the appropriate subdirectory.
However my asterisk server is still running and it still has that file open. I don't know if this keeps new processes referencing the .so file that is open in ram. I'm not sure how the package manager addresses such issues. Does it run ldconfig as part of the installation and defer resolving issues till the involved files are closed?
For the moment I have again undoed the installation
I was waiting to post this till things were slow enough to restart processes, run ldconfig, etc... Perhaps I need to do the install when no odbc|maria|mysql files are open.
But this is the current state of things, and I will post the outcome later.
John
On Tue, Oct 31, 2017 at 2:52 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/30/2017 12:22 PM, John Harragin wrote:
[root@ec-ast yum.repos.d]# ldd /usr/lib64/libmyodbc5w.so | grep -iE "my|maria" libmysqlclient.so.18 => /usr/lib64/mysql/libmysqlclient.so.18 (0x00007f3dfb34c000) [root@ec-ast yum.repos.d]# repoquery -l MariaDB-server MariaDB-client MariaDB-commo MariaDB-shared galera boost-program-options jemalloc rsync lsof | grep lib64 | grep libmysqlclient /usr/lib64/libmysqlclient.so.18
If the MariaDB packages provide the library in /usr/lib64, what provides the lib in /usr/lib64/mysql? (It looks like you have a library conflict)
rpm -qf /usr/lib64/mysql/*
More than likely, you can resolve the problem by removing the package that provides the files in /usr/lib64/mysql/. However, as Alexander pointed out, this isn't a problem with the CentOS packages, and you're more likely to get useful information if you address this question to the vendor of the broken package.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/31/2017 12:23 PM, John Harragin wrote:
However my asterisk server is still running and it still has that file open. I don't know if this keeps new processes referencing the .so file that is open in ram.
No. New processes will use the .so that they find in their library path, in the filesystem.
I'm not sure how the package manager addresses such issues.
It doesn't.
Does it run ldconfig as part of the installation and defer resolving issues till the involved files are closed?
Packages may specifically run "ldconfig" in their post install script (rpm -q --scripts), but rpm won't otherwise.
If you remove a package that provides an .so file, the files are deleted from the filesystem by rpm. If those files are open by an active process, the inode and data blocks will not be freed by the kernel at that time, because there is still an in-memory reference to those. When those processes exit, the reference count is decreased. When the reference count reaches zero, and nothing refers to that inode any longer, the kernel will clear the inode and free the data blocks it is using.
Thanks.
I just installed mariadb-server 10.1 and tried a series of things and could not get it to work. So once again I yum undo-ed to uninstall
So if I am understanding correctly, tomorrow I can reinstall mariadb-server, my already running process will continue to run (as it does), and by opening isql a new instance of unixodbc, mysql-connector... the whole linkage chain. should be established so I can hopefully figure out what is happening?
I'll also look around in yum's history to see if the is some old component of mysql or mariaclient not getting removed...
What is the likelihood of yum not identifying a prerequisite?
Quitting for now. That is enough of my time given to work for one night!
John
On Tue, Oct 31, 2017 at 3:57 PM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/31/2017 12:23 PM, John Harragin wrote:
However my asterisk server is still running and it still has that file open. I don't know if this keeps new processes referencing the .so file that is open in ram.
No. New processes will use the .so that they find in their library path, in the filesystem.
I'm not sure how the package manager addresses such
issues.
It doesn't.
Does it run ldconfig as part of the installation and defer
resolving issues till the involved files are closed?
Packages may specifically run "ldconfig" in their post install script (rpm -q --scripts), but rpm won't otherwise.
If you remove a package that provides an .so file, the files are deleted from the filesystem by rpm. If those files are open by an active process, the inode and data blocks will not be freed by the kernel at that time, because there is still an in-memory reference to those. When those processes exit, the reference count is decreased. When the reference count reaches zero, and nothing refers to that inode any longer, the kernel will clear the inode and free the data blocks it is using.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-
Alexander Dalloz -
Gordon Messmer -
John Harragin