{"id":1461,"date":"2020-04-22T14:30:25","date_gmt":"2020-04-22T17:30:25","guid":{"rendered":"https:\/\/thesqltimes.com\/blog\/?p=1461"},"modified":"2020-04-22T16:24:09","modified_gmt":"2020-04-22T19:24:09","slug":"sql-linux-unable-read-instanceid","status":"publish","type":"post","link":"https:\/\/thesqltimes.com\/blog\/2020\/04\/22\/sql-linux-unable-read-instanceid\/","title":{"rendered":"SQL on Linux: Erro Unable to read instance id from \/var\/opt\/mssql\/.system\/instance_id"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>Tempo de Leitura:<\/span> 4<\/span> minutos<\/span><\/span>

Na \u00faltima segunda-feira (20\/04\/2020), v\u00e9spera de feriado, um cliente da Power Tuning nos chamou dizendo que o seguinte erro ocorreu no SQL Server em um Ubuntu:<\/p>\n

systemd[1]: mssql-server.service: Main process exited, code=killed, status=6\/ABRT
\nsystemd[1]: mssql-server.service: Unit entered failed state.
\nsystemd[1]: mssql-server.service: Failed with result ‘signal’.
\nsystemd[1]: mssql-server.service: Service hold-off time over, scheduling restart.
\nsystemd[1]: Stopped Microsoft SQL Server Database Engine.
\nsystemd[1]: mssql-server.service: Start request repeated too quickly.
\nsystemd[1]: Failed to start Microsoft SQL Server Database Engine.
\nsystemd[1]: mssql-server.service: Unit entered failed state.
\nsystemd[1]: mssql-server.service: Failed with result ‘start-limit-hit’.<\/div>\n
<\/div>\n

Para quem est\u00e1 acostumado com Linux, este \u00e9 um t\u00edpico erro reportado pelo systemd<\/a> (um gerenciador de servi\u00e7o do Linux) quando o servi\u00e7o falha ao iniciar, at\u00e9 esgotar as tentativas.<\/p>\n

Como no bom e velho Windows, a alternativa aqui \u00e9 analisar com mais detalhes os logs. No caso, o meu “Event Viewer” \u00e9 o comando journalctl<\/a>, e estou interessando em um servi\u00e7o chamado mssql-server<\/strong>:<\/p>\n

\n
journalctl -u mssql-server<\/pre>\n
\"\"<\/p>\n<\/div>\n
O log foi esse, e eu marquei as partes que mais me chamaram a aten\u00e7\u00e3o:<\/p>\n
sqlservr[1202]: sqlservr: Unable to read instance id from \/var\/opt\/mssql\/.system\/instance_id<\/strong>: Success (0)
\nsqlservr[1202]: This program has encountered a fatal error and cannot continue running at Mon Apr 20 23:24:16 2020
\nsqlservr[1202]: The following diagnostic information is available:
\nsqlservr[1202]: Reason: 0x00000003
\nsqlservr[1202]: Message: Unexpected call to legacy ABI.<\/strong>
\nsqlservr[1202]: Stacktrace: 000055a12a12e464 000055a12a12dfdf 000055a12a07266e
\nsqlservr[1202]: 000055a12a0bf977
\nsqlservr[1202]: Process: 1202 – sqlservr
\nsqlservr[1202]: Thread: 1463
\nsqlservr[1202]: Instance Id:
\nsqlservr[1202]: Crash Id:
\nsqlservr[1202]: Build stamp: 70437f6583b8ef39b1ef70539ef84690980315dc7a4436c9c40015f28610e4aa
\nsqlservr[1202]: Distribution: Ubuntu 16.04.5 LTS
\nsqlservr[1202]: Processors: 2
\nsqlservr[1202]: Total Memory: 8061263872 bytes
\nsqlservr[1202]: Timestamp: Mon Apr 20 23:24:16 2020<\/p>\n
Pesquisando exatamente a mensagem destacada da primeira linha, eu\u00a0 cheguei a esta resposta do Andrew Matta<\/a> no f\u00f3rum msdn. Ele teve um problema parecido e sugeriu mover este arquivo instance_id<\/strong>. Se voc\u00ea notou, este arquivo fica num diret\u00f3rio oculto do linux (diret\u00f3rio que come\u00e7a com . (ponto), que, neste caso, \u00e9 o .system<\/strong>).<\/p>\n
Ent\u00e3o, foi isso que eu fiz! Movi o arquivo para um backup:<\/p>\n
\n
mv instance_id instance_id.bak<\/pre>\n
E ent\u00e3o, reiniciei o servi\u00e7o:<\/p>\n
systemctl start mssql-server<\/pre>\n
E o servi\u00e7o voltou normalmente!<\/p>\n<\/div>\n
Curiosamente, aqui est\u00e1 o conte\u00fado do arquivo original, antes de mover:<\/p>\n
<\/p>\n
E aqui, est\u00e1 o arquivo ap\u00f3s o restart (o sql recriou ele):<\/p>\n
<\/p>\n
Por algum motivo, o arquivo original perdeu a primeira linha, e deveria existir algum valor l\u00e1. Infelizmente, a documenta\u00e7\u00e3o internals do SQL Server on Linux<\/strong> carece de alguns detalhes. Eu busquei esse nome de arquivo e cheguei neste KB da Microsoft sobre um FIX<\/a>, que de quebra ele fala um pouco mais sobre o arquivo misterioso:<\/p>\n
\"\"<\/p>\n
Este arquivo pode conter diversas informa\u00e7\u00f5es codificada nestes n\u00fameros. Conforme o artigo, uma delas parece ser a fonte do NEWSEQUENTIALID, que gera identificadores universais e sequenciais (UUID).<\/p>\n
Outra coisa que mais me chamou a aten\u00e7\u00e3o foi a mensagem “Success (0)” na primeira linha log acima, que, num primeiro momento, me enganou, desviando a minha aten\u00e7\u00e3o dele. Eu subi um SQL 2019 em Ubuntu (e um 2017 tamb\u00e9m), e fiz algumas brincadeiras com este arquivo, mas n\u00e3o consegui obter exatamente a mesma mensagem:<\/p>\n
\"\"<\/p>\n
Consegui reproduzir o problema em parte, mas ainda preciso de mais testes para identificar isso tudo.<\/p>\n
A percep\u00e7\u00e3o que tive \u00e9 que, quando este arquivo cont\u00e9m dados inv\u00e1lidos, ou faltantes, o SQL se atrapalha e gera um dump, e por isso estamos vendo esse monte de mensagens com bin\u00e1rios, stacks e informa\u00e7\u00f5es de processo. A melhor sa\u00edda \u00e9 fazer o backup deste arquivo e deixar o SQL criar um outro. Isso pode gerar uma inconsist\u00eancia se voc\u00ea usa NEWSEQUENTIALID<\/a>.<\/p>\n
O que pode ter causado isso?<\/strong><\/p>\n
Uma boa pergunta. O cliente me informou que todos os dias desliga esta m\u00e1quina. Ent\u00e3o, meu melhor palpite \u00e9 que, durante um dos desligamentos, o SQL Server foi interrompido abruptamente, e ele se atrapalhou quando estava mexendo nesse arquivo. De novo, isso \u00e9 apenas uma suspeita minha e ainda n\u00e3o comprovei! Quando eu descobrir isso, eu atualizo o post.<\/p>\n
Eu ainda n\u00e3o encontrei muita refer\u00eancia sobre este arquivo e assim que o fizer, eu irei atualizar este post. Ali\u00e1s, todo o diret\u00f3rio .system<\/strong><\/em> que fica na “home<\/strong>” da instala\u00e7\u00e3o do SQL on Linux, cont\u00e9m uma mundo m\u00e1gico que vale a pena ser explorado… Quem sabe num futuro pr\u00f3ximo n\u00e3o voltamos com mais posts sobre isso aqui no blog!<\/p>\n
At\u00e9 mais!<\/p>\n
<\/div>\n
<\/div>\n
<\/div>\n","protected":false},"excerpt":{"rendered":"
Na \u00faltima segunda-feira (20\/04\/2020), v\u00e9spera de feriado, um cliente da Power Tuning nos chamou dizendo que o seguinte erro ocorreu no SQL Server em um Ubuntu: systemd[1]: mssql-server.service: Main process exited, code=killed, status=6\/ABRT systemd[1]: mssql-server.service: Unit entered failed state. systemd[1]: mssql-server.service: Failed with result ‘signal’. systemd[1]: mssql-server.service: Service hold-off time over, scheduling restart. systemd[1]: Stopped… SQL on Linux: Erro Unable to read instance id from \/var\/opt\/mssql\/.system\/instance_id<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":1462,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[8,296,318,7],"tags":[321,209,322,319,73,320],"series":[],"class_list":["post-1461","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administracao","category-internals","category-sql-on-linux","category-sql-server","tag-instance_id","tag-linux","tag-newsequentialid","tag-sql-on-linux","tag-sql-server","tag-systemctl"],"_links":{"self":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts\/1461","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/comments?post=1461"}],"version-history":[{"count":9,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts\/1461\/revisions"}],"predecessor-version":[{"id":1476,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts\/1461\/revisions\/1476"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/media\/1462"}],"wp:attachment":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/media?parent=1461"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/categories?post=1461"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/tags?post=1461"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/series?post=1461"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}