4

We recently had a Ubuntu 16.04 server loose power. After restarting the server I noticed that MSSQL Server was no longer running due to a an error Unexpected call to legacy ABI. After researching for hours I could not solve the issue.

I then uninstalled MSSQL Server fully and reinstalled it. I went through the configure prompts although when choosing version (SQL Server Express) it would give an error ValueError: unknown locale: UTF-8 I then solved that by doing the following 2 commands:

$ export LC_ALL=en_US.UTF-8
$ export LANG=en_US.UTF-8

Which solved that issue, although after entering the system admin passwords I get this error:

This program has encountered a fatal error and cannot continue running at Wed Apr 15 21:46:52 2020
The following diagnostic information is available:

         Reason: 0x00000003
         Status: 0x00000000
        Message: Unexpected call to legacy ABI.
          Stack:
                 IP               Function
                 ---------------- --------------------------------------
                 0000561aed8a2ada std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
                 0000561aed8a25d9 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
                 0000561aed7ea9ae std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c?*??~
                 0000561aed848717 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > std::__1::operator+<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > c
        Process: 20452 - sqlservr
         Thread: 20454
    Instance Id: ae93b937-d981-4d99-b419-bff7970c8bfb
       Crash Id: 
    Build stamp: 79eb721ef02d0426160fe0ad320e7425f9d012fbe368753d2655c5bce25b1b3c
   Distribution: Ubuntu 16.04.6 LTS
     Processors: 4
   Total Memory: 8239382528 bytes
      Timestamp: Wed Apr 15 21:46:52 2020
/opt/mssql/lib/mssql-conf/invokesqlservr.sh: line 15: 20451 Aborted                 (core dumped) sudo -EH -u mssql /bin/bash -c "$CMDLINE"
Setup has completed successfully. SQL Server is now starting.

And the service is in a failed state.

Any suggestions?

2 Answers 2

0

I found this:

Short answer: Try renaming /var/opt/mssql/.system/instance_id to something else, and restart SQL Server.

Rationale:

I was running into this issue on Linux Mint. I started noticing the problem after having done a system update and a reboot.

I tried reinstalling SQL Server 2017 (same error), upgrading to the preview of 2019 (same error), and removing all the packages and using Docker instead.

I noticed that starting the Docker image actually started SQL Server normally (although with none of my databases since the data is stored inside the container by default). After starting the docker image with the "-v /var/opt/mssql:/var/opt/mssql" option telling it to utilize my existing databases, I got the exact same error about an Unexpected call to legacy ABI.

I noticed that one of the first lines in the error said "sqlservr: Unable to read instance id from /var/opt/mssql/.system/instance_id: No such file or directory (2)". I tried reading that file, and it actually DID exist.

I moved the existing file out of the way: mv /var/opt/mssql/.system/instance_id /var/opt/mssql/.system/instance_id.bak Then started SQL Server again - and it worked.

So - some sort of corruption in the instance_id file or something related to it? The original (corrupted?) file only had two lines, while the newly-regenerated file had three lines, the first of which is dash-separated value that was not present in the original file.

I'm not certain if this will have lingering consequences for my databases (not a big deal for me, as it's just dev data) - but so far it appears to be functioning.

I have tried this under centos 7 and for me it didn't help.

0

Short answer: Try renaming /var/opt/mssql/.system/instance_id to something else, and restart SQL Server. It worked for me

1
  • Thank you for the suggestion. Unfortunately this server was decommissioned 3 years ago so have no way to test.
    – DDiamond
    Commented Feb 15 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.