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 at gmail.com> wrote:> On 10/30/2017 12:22 PM, John Harragin wrote: > >> [root at 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 at 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 at 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 at 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 at centos.org > https://lists.centos.org/mailman/listinfo/centos >
What I have found is that the only new shared objects between the different versions of the running isqls is: < lrwxrwxrwx. 1 root root 24 Oct 31 21:25 /usr/lib64/mysql/libmysqlclient.so.18 -> libmysqlclient.so.18.0.0> lrwxrwxrwx. 1 root root 24 Nov 2 12:13/usr/lib64/mysql/libmysqlclient.so.18 -> libmysqlclient.so.18.0.0 ... also this is the only shared object with a different node-ID between the 2 instances.>From the journal:Nov 02 12:17:23 ec-ast kernel: isql[39065]: segfault at 10070 ip 00007ff0998b3f7e sp 00007ffc9693bb90 error 4 in libmyodbc5w.so[7ff09988d000+47000] # yum search odbc | grep -E "my|mar" mysql-connector-odbc.x86_64 : ODBC driver for MySQL [root at ec-ast unixodbcproblem]# yum info mysql-connector-odbc.x86_64 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirrors.lga7.us.voxel.net * epel: epel.mirror.constant.com * extras: mirror.atlanticmetro.net * updates: mirror.atlanticmetro.net Installed Packages Name : mysql-connector-odbc Arch : x86_64 Version : 5.2.5 Release : 6.el7 Size : 427 k Repo : installed>From repo : baseSummary : ODBC driver for MySQL URL : http://dev.mysql.com/downloads/connector/odbc/ License : GPLv2 with exceptions Description : An ODBC (rev 3) driver for MySQL, for use with unixODBC. yum whatprovides '*libmyodbc5w.so' ...indicates that this is the only source (for my Repo list) for this package which contains the segfaulting file. ... On Thu, Nov 2, 2017 at 1:38 PM, John Harragin <jharragi at mw.k12.ny.us> wrote:> OK, I tried again. I ran the following series of commands (some output in > attached file): > > On a separate session, the first sqli process 29669 worked continually. > On a separate session (after mariadb-server 10.1 is installed), isql opens > (proc 39065), but SegFaults upon running a query. > > > mkdir /tmp/unixodbcproblem > ps -A | grep isql > PROCESS=29669 > lsof | grep ${PROCESS} > /tmp/unixodbcproblem/lsof.${PROCESS} > for f in $(pldd ${PROCESS}); do ls -l $f; done > > /tmp/unixodbcproblem/pldd.${PROCESS} > yum install mariadb-server > ps -A | grep isql > PROCESS=39065 > lsof | grep ${PROCESS} > /tmp/unixodbcproblem/lsof.${PROCESS} > for f in $(pldd ${PROCESS}); do ls -l $f; done > > /tmp/unixodbcproblem/pldd.${PROCESS} > setenforce 0 # Ran isql again. Still segmentation > fault. Just to make sure this not the problem > sestatus > yum history list # This reported the most recent > mariadb-server install as: 53 > yum history undo 53 > exit > > # ls /tmp/unixodbcproblem/ > lsof.29669 lsof.39065 pldd.29669 pldd.39065 > > > > This is what I get when mariadb-server 10.1 is installed: > > # isql -vv mccmysql ec-ast ec > +---------------------------------------+ > | Connected! | > | | > | sql-statement | > | help [tablename] | > | quit | > | | > +---------------------------------------+ > SQL> SELECT e_extnum FROM ext LIMIT 5; > Segmentation fault > > > This is what I get when mariadb-server is not installed: > > # isql -vv mccmysql ec-ast ec > +---------------------------------------+ > | Connected! | > | | > | sql-statement | > | help [tablename] | > | quit | > | | > +---------------------------------------+ > SQL> SELECT e_extnum FROM ext LIMIT 1; > +---------+ > | e_extnum| > +---------+ > | 6011 | > +---------+ > SQLRowCount returns 1 > 1 rows fetched > SQL> quit > > > I going to sed & diff... these files to see what I find. If anyone has any > suggestions of tools for this type of investigation, I would love to hear > about it. > > John >
I think the solution may exist. The compatibility of mysql-connector-odbc with maria may just means the driver can access the mariadb - but my experience suggests not live on the same host. maria has its own connector: https://downloads.mariadb.org/connector-odbc/ it does not look like this is in the sig, so I'll have to turn to the maria repo. I'll try replacing the driver first, then install the server - and I may be good to go. On Fri, Nov 3, 2017 at 10:23 AM, John Harragin <jharragi at mw.k12.ny.us> wrote:> What I have found is that the only new shared objects between the > different versions of the running isqls is: > > < lrwxrwxrwx. 1 root root 24 Oct 31 21:25 /usr/lib64/mysql/libmysqlclient.so.18 > -> libmysqlclient.so.18.0.0 > > lrwxrwxrwx. 1 root root 24 Nov 2 12:13 /usr/lib64/mysql/libmysqlclient.so.18 > -> libmysqlclient.so.18.0.0 > > ... also this is the only shared object with a different node-ID between > the 2 instances. > > > From the journal: > > Nov 02 12:17:23 ec-ast kernel: isql[39065]: segfault at 10070 ip > 00007ff0998b3f7e sp 00007ffc9693bb90 error 4 in libmyodbc5w.so[7ff09988d000+ > 47000] > > # yum search odbc | grep -E "my|mar" > mysql-connector-odbc.x86_64 : ODBC driver for MySQL > > [root at ec-ast unixodbcproblem]# yum info mysql-connector-odbc.x86_64 > Loaded plugins: fastestmirror > Loading mirror speeds from cached hostfile > * base: mirrors.lga7.us.voxel.net > * epel: epel.mirror.constant.com > * extras: mirror.atlanticmetro.net > * updates: mirror.atlanticmetro.net > Installed Packages > Name : mysql-connector-odbc > Arch : x86_64 > Version : 5.2.5 > Release : 6.el7 > Size : 427 k > Repo : installed > From repo : base > Summary : ODBC driver for MySQL > URL : http://dev.mysql.com/downloads/connector/odbc/ > License : GPLv2 with exceptions > Description : An ODBC (rev 3) driver for MySQL, for use with unixODBC. > > yum whatprovides '*libmyodbc5w.so' > ...indicates that this is the only source (for my Repo list) for this > package which contains the segfaulting file. > > ... > > On Thu, Nov 2, 2017 at 1:38 PM, John Harragin <jharragi at mw.k12.ny.us> > wrote: > >> OK, I tried again. I ran the following series of commands (some output in >> attached file): >> >> On a separate session, the first sqli process 29669 worked continually. >> On a separate session (after mariadb-server 10.1 is installed), isql >> opens (proc 39065), but SegFaults upon running a query. >> >> >> mkdir /tmp/unixodbcproblem >> ps -A | grep isql >> PROCESS=29669 >> lsof | grep ${PROCESS} > /tmp/unixodbcproblem/lsof.${PROCESS} >> for f in $(pldd ${PROCESS}); do ls -l $f; done > >> /tmp/unixodbcproblem/pldd.${PROCESS} >> yum install mariadb-server >> ps -A | grep isql >> PROCESS=39065 >> lsof | grep ${PROCESS} > /tmp/unixodbcproblem/lsof.${PROCESS} >> for f in $(pldd ${PROCESS}); do ls -l $f; done > >> /tmp/unixodbcproblem/pldd.${PROCESS} >> setenforce 0 # Ran isql again. Still segmentation >> fault. Just to make sure this not the problem >> sestatus >> yum history list # This reported the most recent >> mariadb-server install as: 53 >> yum history undo 53 >> exit >> >> # ls /tmp/unixodbcproblem/ >> lsof.29669 lsof.39065 pldd.29669 pldd.39065 >> >> >> >> This is what I get when mariadb-server 10.1 is installed: >> >> # isql -vv mccmysql ec-ast ec >> +---------------------------------------+ >> | Connected! | >> | | >> | sql-statement | >> | help [tablename] | >> | quit | >> | | >> +---------------------------------------+ >> SQL> SELECT e_extnum FROM ext LIMIT 5; >> Segmentation fault >> >> >> This is what I get when mariadb-server is not installed: >> >> # isql -vv mccmysql ec-ast ec >> +---------------------------------------+ >> | Connected! | >> | | >> | sql-statement | >> | help [tablename] | >> | quit | >> | | >> +---------------------------------------+ >> SQL> SELECT e_extnum FROM ext LIMIT 1; >> +---------+ >> | e_extnum| >> +---------+ >> | 6011 | >> +---------+ >> SQLRowCount returns 1 >> 1 rows fetched >> SQL> quit >> >> >> I going to sed & diff... these files to see what I find. If anyone has >> any suggestions of tools for this type of investigation, I would love to >> hear about it. >> >> John >> > >