문의자
Problem starting mssql service on Linux

질문
-
Hi,
I'm having an issue when starting my mssql-server.service on Linux.
The following error message is generated:
sqlservr: Unable to read instance id from /var/opt/mssql/.system/instance_id: Success (0)
This program has encountered a fatal error and cannot continue running at Wed May 15 12:24:22 2019
The following diagnostic information is available:
Reason: 0x00000003
Message: Unexpected call to legacy ABI.
Stacktrace: 000055c1f94c6464 000055c1f94c5fdf 000055c1f940a66e
000055c1f9457977
Process: 23721 - sqlservr
Thread: 23722
Instance Id:
Crash Id:
Build stamp: 70437f6583b8ef39b1ef70539ef84690980315dc7a4436c9c40015f28610e4aa
Distribution: Ubuntu 16.04.6 LTS
Processors: 4
Total Memory: 12598861824 bytes
Timestamp: Wed May 15 12:24:22 2019
Aborted (core dumped)Does anybody know what is wrong, and why i get this error message?
Any help is appreciated
2019년 5월 15일 수요일 오전 11:26
모든 응답
-
Hi KasperKimose,
Which version of SQL Server are you using? And try to reinstall mssql server and all dependencies. Please refer to Quickstart: Install SQL Server and create a database on Ubuntu.Best Regards,
Puzzle
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com2019년 5월 16일 목요일 오전 2:05 -
Hi Puzzle & KasperKimose
I've started to get the same issue. Has anyone been able to fix this if so how? I've tried updating MSSQL again but no difference.
mssql-server is already the newest version (14.0.3192.2-2).
-- The start-up result is RESULT.
sqlservr: Unable to read instance id from /var/opt/mssql/.system/instance_id: Success (0)
This program has encountered a fatal error and cannot continue running at Wed Jul 17 23:15:43 2019
The following diagnostic information is available:
Reason: 0x00000003
Status: 0x00000000
Message: Unexpected call to legacy ABI.
Stack:
IP Function
---------------- --------------------------------------
000055fd31b4bbbd malloc_usable_size+0xc4e2d
000055fd31b4b797 malloc_usable_size+0xc4a07
000055fd31a9599e malloc_usable_size+0xec0e
000055fd31ad7bb7 malloc_usable_size+0x50e27
Process: 23907 - sqlservr
Thread: 23908
Instance Id:
Crash Id:
Build stamp: b41fc6a491ffb5396769a1284eb6d66e333bfc61f3db7874d3aa0889a875241e
Distribution: Ubuntu 18.04.2 LTS
Processors: 24
Total Memory: 33607151616 bytes
Timestamp: Wed Jul 17 23:15:43 2019
mssql-server.service: Main process exited, code=killed, status=6/ABRT
mssql-server.service: Failed with result 'signal'.
mssql-server.service: Service hold-off time over, scheduling restart.
mssql-server.service: Scheduled restart job, restart counter is at 3.
2019년 7월 17일 수요일 오후 9:34 -
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.2019년 7월 25일 목요일 오후 6:25