I created a machine with 6 GB of memory, using Ubuntu 20, and installed the latest version of SQL Server Microsoft SQL Server:
(RTM-CU8) (KB4577194) - 15.0.4073.23 (X64)
Sep 23 2020 16:03:08
Copyright (C) 2019 Microsoft Corporation
Express Edition (64-bit) on Linux (Ubuntu 20.04.1 LTS)
Exporadically the system suffers a fatal failure and restarts, taking almost a minute to return. I cannot detect the real reason for the failure and what I could do to resolve it.
I already set the maximum memory limit to 4gb thinking that the system was overflowing the machine's limit. Help me please
This program has encountered a fatal error and cannot continue running
at Mon Dec 21 14:31:38 2020 The following diagnostic information is
available:
Reason: 0x00000006
Message: Kernel bug check
Address: 0x3fff86a3be90
Parameters: 0xca6e6e240
Stack Trace:
file://package4/windows/system32/sqlpal.dll+0x000000000030E7D9
file://package4/windows/system32/sqlpal.dll+0x000000000030C769
file://package4/windows/system32/sqlpal.dll+0x000000000023BEEB
file:///windows/System32/Drivers/Afd.sys+0x0000000000006385
file:///windows/System32/Drivers/Afd.sys+0x000000000000686F
file:///windows/System32/Drivers/Afd.sys+0x000000000000631A
file://package4/windows/system32/sqlpal.dll+0x00000000002412B6
file://package4/windows/system32/sqlpal.dll+0x0000000000202FE2
file://package4/windows/system32/sqlpal.dll+0x0000000000347898
file:///Windows/system32/mswsock.dll+0x00000000000015EC
file:///Windows/SYSTEM32/WS2_32.dll+0x000000000000A6BE
file:///binn/sqllang.dll+0x00000000003C90B6
file:///binn/sqllang.dll+0x00000000003C9854
file:///binn/sqllang.dll+0x00000000000149CD
file:///binn/sqllang.dll+0x0000000000014DBA
file:///binn/sqllang.dll+0x00000000001FA73B
file:///binn/sqllang.dll+0x00000000001FA663
file:///binn/sqllang.dll+0x00000000001FA0EF
file:///binn/sqldk.dll+0x0000000000009FF3
file:///binn/sqldk.dll+0x000000000000A92D
file:///binn/sqldk.dll+0x000000000000A51E
file:///binn/sqldk.dll+0x00000000000217F2
file:///binn/sqldk.dll+0x000000000002215C
file:///binn/sqldk.dll+0x0000000000021F53
file:///Windows/SYSTEM32/KERNEL32.DLL+0x0000000000014414
file:///windows/system32/ntdll.dll+0x0000000000075541
+0x00000000E7E27000
Process: 90917 - sqlservr
Thread: 99182 (application thread 0x2c34)
Instance Id: 8638650d-adf3-4e7e-8b1b-6cdecd05544c
Crash Id: 43334ff2-47c7-4fb5-a22e-16f4e0728252
Build stamp: 98b2cf08cbfec4dc5f2c5d0e2a892c88d339a4da408744f2baf39941a977fa3c
Distribution: Ubuntu 20.04.1 LTS
Processors: 4 Total Memory: 6234537984 bytes
Timestamp: Mon Dec 21 14:31:38 2020
Last errno: 11 Last errno text: Resource temporarily unavailable Ubuntu 20.04.1 LTS Capturing core dump and information to
/var/opt/mssql/log... #033[0;1;39mHint: You are currently not seeing
messages from other users and the system.#033[0m #033[0;1;39m
Users in groups 'adm', 'systemd-journal' can see all messages.#033[0m
#033[0;1;39m Pass -q to turn off this notice.#033[0m #033[0;1;31mNo journal files were opened due to insufficient permissions.#033[0m #033[0;1;39mHint: You are currently not seeing
messages from other users and the system.#033[0m #033[0;1;39m
Users in groups 'adm', 'systemd-journal' can see all messages.#033[0m
#033[0;1;39m Pass -q to turn off this notice.#033[0m #033[0;1;31mNo journal files were opened due to insufficient permissions.#033[0m /usr/bin/tail: cannot open '/var/log/syslog' for
reading: Permission denied Mon 21 Dec 2020 02:31:40 PM -03 Capturing
program information Mon 21 Dec 2020 02:31:42 PM -03 Attempting to
capture a dump with paldumper for pid 90917
Related
I started having this issue today on our production sql server. I have tried a variety of different fixes proposed online. We are using MSSQL server 2017 (14.0.3257.3-13). I'm out of ideas on what could be causing the server to crash. Below is the recent crash log.
This program has encountered a fatal error and cannot continue running at Sat Feb 1 14:21:21 2020
The following diagnostic information is available:
Reason: 0x00000007
Status: 0xc000014c
Message: Corruption detected in persistent registry: \SystemRoot\security.hiv.
Stack Trace:
000000006b137250
000000006b1345bf
000000006b1347a3
000000006b1337d3
000000006b1326f2
000000006b175c31
Process: 8815 - sqlservr
Thread: 8819 (application thread 0x4)
Instance Id: e5a2f812-0426-4d92-b9b2-1db1e60d957c
Crash Id: 60073e70-4042-4275-9fcd-a05ae84d26f5
Build stamp: 9726a6583fe7826f57b03fd1c7adf12bebe7692cb64630fccb0541c06820af4d
Distribution: Ubuntu 16.04.6 LTS
Processors: 9
Total Memory: 8589934592 bytes
Timestamp: Sat Feb 1 14:21:21 2020
Last errno: 2
Last errno text: No such file or directory
Thank you for the ideas, Toret.
I have faced the same issue, but I solved it just by deleting the security.hiv file.
rm /var/opt/mssql/.system/system/security.hiv
After that the mssql-server service started normaly.
After working through multiple proposed solutions online nothing worked. Some of the things I tried:
Upgrading mssql-server to latest version.
Repairing missing files or dependencies.
Changing access permissions to the directory.
Elevating access permissions for the mssql user.
Changing user access to root for the .hiv files located in the mssql .system/system folder
The only way to for me to get it to work was to:
Delete all the folders manually from /var/opt/mssql/ except for the
data folder.
Re-link python from 3.5 to 2.7
Then I downgraded the mssql-server version to Microsoft SQL Server 2017 14.0.3192.2.
Run the sudo /opt/mssql/bin/mssql-conf setup
**Python Re-link**
sudo rm /user/bin/python
sudo ln -s /user/bin/python[version] /user/bin/python
After that everything worked again.
How to uninstall everything: mvfs, all services, albd, all files and folders?
For information a cleartool hostinfo -properties gives:
ClearCase 8.0.1.4 (AIX 1 7)
Scaling factor to initialize MVFS cache sizes: 24
MVFS cache sizes:
Free mnodes: 13967
Free mnodes for cleartext: 13967
File names: 20000
Directory names: 5000
Names not found: 20000
RPC handles: 240
Initial mnode table size: 63488
Blocks per directory: 6
Minimum free mnodes: 12570
Minimum free mnodes for cleartext: 13167
Cleartext idle lifetime: 259200
VOB hash table size: 8192
Cleartext hash table size: 2048
DNC hash table size: 4507
Thread hash table size: 511
Process hash table size: 511
Installed product: MultiSite version 8.0.1.1 (Fri Sep 20 16:09:14 EDT 2013) (8.0.1.01.00_2013C.FCS)
Installed product: MultiSite version 8.0.1.2 (Wed Dec 11 16:09:14 EDT 2013) (8.0.1.02.00_2013D.FCS)
Installed product: MultiSite version 8.0.1.3 (Wed Mar 19 00:31:17 EST 2014) (8.0.1.03.00_2014A.FCS)
Installed product: MultiSite version 8.0.1.3-iFix01 (Tue Apr 22 18:14:02 EDT 2014) (8.0.1.03.01_2014A.1.FCS)
Installed product: MultiSite version 8.0.1.04 (Wed Jun 11 00:31:23 EDT 2014) (8.0.1.04.00_2014B.D140610)
Installed product: ClearCase version 8.0.1.1 (Fri Sep 20 16:09:14 EDT 2013) (8.0.1.01.00_2013C.FCS)
Installed product: ClearCase version 8.0.1.2 (Wed Dec 11 16:09:14 EDT 2013) (8.0.1.02.00_2013D.FCS)
Installed product: ClearCase version 8.0.1.3 (Wed Mar 19 00:31:17 EST 2014) (8.0.1.03.00_2014A.FCS)
Installed product: ClearCase version 8.0.1.3-iFix01 (Tue Apr 22 18:14:02 EDT 2014) (8.0.1.03.01_2014A.1.FCS)
Installed product: ClearCase version 8.0.1.04 (Wed Jun 11 00:31:23 EDT 2014) (8.0.1.04.00_2014B.D140610)
This was installed via IBM installation Manager (IM), are you unable to uninstall it via Installation Manager? Most people try to use the GUI interface to IM, but if
there isn't enough XWindows installed, or
some of the GUI libraries are the wrong versions for the Eclipse shell to start, or
You are using telnet (Odd, but you can) or SSH without X forwarding,
you may get some "helpful" error messages. You can use the "imcl" command to do this from a terminal session by (note these paths are DEFAULT, and may not match your setup as a result) running:
/opt/IBM/InstallationManager/eclipse/tools/imcl -c
And following the prompts to remove that version of ClearCase. I recall CC 8.0.1 allows removal on the command line for this very reason. (Installing, upgrading, and uninstalling on Unix hosts without requiring X or X-forwards.)
I have installed mssql on Ubuntu 16.04. following are the details of sql server.
ms sql (14.0.3015.40-1) i.e SQL server 2017.
when I run the configuration command #sudo /opt/mssql/bin/sqlservr-setup
I got error sudo: /opt/mssql/bin/sqlservr-setup: command not found
I have stopped and restarted but of no use.
When I check the status by command #systemctl status mssql-server
I got
mssql-server.service - Microsoft SQL Server Database Engine
Loaded: loaded (/lib/systemd/system/mssql-server.service; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: exit-code) since Fri 2018-02-02 16:15:29 IST; 4min 20s ago
Docs: https://learn.microsoft.com/en-us/sql/linux
Process: 28050 ExecStart=/opt/mssql/bin/sqlservr (code=exited, status=200/CHDIR)
Main PID: 28050 (code=exited, status=200/CHDIR)
Feb 02 16:15:28 chetan-desktop systemd[1]: mssql-server.service: Unit entered failed state.
Feb 02 16:15:28 chetan-desktop systemd[1]: mssql-server.service: Failed with result 'exit-code'.
Feb 02 16:15:29 chetan-desktop systemd[1]: mssql-server.service: Service hold-off time over, scheduling restart.
Feb 02 16:15:29 chetan-desktop systemd[1]: Stopped Microsoft SQL Server Database Engine.
Feb 02 16:15:29 chetan-desktop systemd[1]: mssql-server.service: Start request repeated too quickly.
Feb 02 16:15:29 chetan-desktop systemd[1]: Failed to start Microsoft SQL Server Database Engine.
I have googled and tried all possible options. But unable to start SQL server.
Please guide me through this.
I had the same two problems.
First, I was referencing very old documentation that applied to an early (preview) release for RHEL, and so I was using the wrong command. The correct command is:
/opt/mssql/bin/mssql-conf setup
Second, the service was failing to start because my virtual machine did not have enough RAM available (SQL Server on Linux requires at least 2GiB of RAM available.) The documentation I was referred to incorrectly stated that only 0.5GiB was required, this is incorrect and journalctl was not providing any useful information about the start failure.
After configuring available memory to 2GiB and using the correct mssql-conf command I was able to successfully configure and start an MSSQL Server instance on Linux.
References:
Configure SQL Server on Linux with the mssql-conf tool (Microsoft Docs)
KB052969: FIX: Minimum memory limit set to 2GB to install or start SQL Server 2017 (Microsoft Support)
Installation guidance for SQL Server on Linux (Microsoft Docs)
The error says that the executable wasn't found in this path, not that the service couldn't start.
According to the installation instructions for Ubuntu you need to run mssql-conf setup to configure the server :
sudo /opt/mssql/bin/mssql-conf setup
not sqlservr-setup
Increasing the RAM size to 3GB on my VM resolved the issue for me.
After installing Oracle Linux 6:
uname -a
Linux ponos 2.6.39-400.109.1.el6uek.x86_64 #1 SMP Tue Jun 4 23:21:51 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux
and making sure that all the pre-required packages are present, I downloaded "Oracle Database 12c Release 1 (12.1.0.1.0) for Linux x86-64", followed the pre-installation instructions and launched the installer.
The installer runs smoothly up to the "Execute Root Scripts" step.
During the "Oracle Database configuration", the "Oracle Net Configuration Assistant" throws error:
[INS-20802] Oracle Net Configuration Assistant failed.
The error log is empty:
-rw-rw----. 1 oracle oinstall 1197690 Jul 8 14:45 installActions2013-07-08_02-18-05PM.log
-rw-rw----. 1 oracle oinstall 0 Jul 8 14:30 oraInstall2013-07-08_02-18-05PM.err
-rw-rw----. 1 oracle oinstall 114 Jul 8 14:30 oraInstall2013-07-08_02-18-05PM.out
Questions:
Has anyone encountered the same problem and managed to resolve it?
Is this configuration essential to install/run the database?
Without closing the installer, try to do retry. It should work second time.
I'm running a single instance mongodb, and the database is crashing all the time.
Anyone knows if this problem is related with running in a single instance?
Tue Aug 9 09:02:59 [initandlisten] connection accepted from 127.0.0.1:60194 #129526
Tue Aug 9 09:17:04 [initandlisten] MongoDB starting : pid=517 port=27017 dbpath=/var/lib/mongodb 32-bit
** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
** see http://blog.mongodb.org/post/137788967/32-bit-limitations
** with --dur, the limit is lower
Tue Aug 9 09:17:04 [initandlisten] db version v1.8.2, pdfile version 4.5
Tue Aug 9 09:17:04 [initandlisten] git version: 433bbaa14aaba6860da15bd4de8edf600f56501b
Tue Aug 9 09:17:04 [initandlisten] build sys info: Linux bs-linux32.10gen.cc 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 BOOST_LIB_VERSION=1_37
old lock file: /var/lib/mongodb/mongod.lock. probably means unclean shutdown
recommend removing file and running --repair
see: http://dochub.mongodb.org/core/repair for more information
Tue Aug 9 09:17:05 [initandlisten] exception in initAndListen std::exception: old lock file, terminating
Tue Aug 9 09:17:05 dbexit:
Tue Aug 9 09:17:05 [initandlisten] shutdown: going to close listening sockets...
Tue Aug 9 09:17:05 [initandlisten] shutdown: going to flush diaglog...
Tue Aug 9 09:17:05 [initandlisten] shutdown: going to close sockets...
Tue Aug 9 09:17:05 [initandlisten] shutdown: waiting for fs preallocator...
Tue Aug 9 09:17:05 [initandlisten] shutdown: closing all files...
Tue Aug 9 09:17:05 closeAllFiles() finished
Tue Aug 9 09:17:05 dbexit: really exiting now
Two Possible Problems:
Look at ulimit -a to see how many open files you're allowed. Each TCP connection counts as an open file. likewise the actual files open. Set this to a high number and see if the crashing stops.
Also, check the value of max processes, it should be at least 4096 or 8192 for a busy server (we've got ours at 32768). Most of these processes are tracking connections, so they are idle most of the time. But, even on an unsharded system, you can get close to those limits.
To check actual open files:
lsof -p <pidnumber>
to check actual processes:
ps axo pid,ppid,rss,vsz,nlwp,cmd | egrep mongod
then look a the nlwp column.
To fix this, do:
man limits.conf
google: limits.conf pam setup ulimit change
to change the values in /etc/security/limits.d/nnn-username.conf
It certainly hasn't anything to do with mongoid since that isn't even a driver, so it doesn't even connect to your db-instance.
Furthermore, I'ld recommend you to post your log-files at https://jira.mongodb.org/.
(but feel free to add some more info to your question, so we may be able to help you here =).)
Usually 32 bit supports data till 2GB of data if you want to store more than that then upgrade to 64 bit. If your data storage is less than 2GB in 32 bit then try ~$ mongod --repair to solve the unclean shutdown probelm.