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 >> > >