On a client's legacy Rails 2.1.1 app, I'm encountering an error where ruby crashes and emits 'Illegal instruction.' The crash is triggered by calls to methods on Digest::SHA2.
>> Digest::SHA2
=> Digest::SHA2
>> Digest::SHA2.new()
Illegal instruction
The Rails app is running on two servers behind a load balancer. The stacks on the two servers are very close to being identical and only one triggers the crash. They're both REE 1.8.7, Rails 2.1 and Debian 6. One is running the Linux kernel version 3.9.3 and one is running version 3.9.2—but I'm unsure how to determine if that's even relevant.
Digest::SHA2 seems to be mostly implemented in C. I know very little C and diagnosing this one is over my head. Any help / pointers in the right direction would be greatly appreciated!
Thanks a bunch!!
Environment Info
Here's the REE source for Digest::SHA2:
https://github.com/FooBarWidget/rubyenterpriseedition187-330/tree/master/ext/digest/sha2
On the server that's encountering the crash:
hostname#node1:~/appname$ cat /etc/issue
Debian GNU/Linux 6.0 \n \l
hostname#node1:~/appname$ uname -a
Linux node1.hostname.org 3.9.2-x86_64-[redacted] #1 SMP Tue May 14 17:16:34 EDT 2013 x86_64 GNU/Linux
hostname#node1:~/appname$ which ruby
/opt/ruby-enterprise-1.8.7-2012.02/bin/ruby
hostname#node1:~/appname$ irb
irb(main):001:0> require 'digest'
=> true
irb(main):002:0> Digest::SHA2.hexdigest('foo')
=> "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae"
irb(main):003:0> exit
hostname#node1:~/appname$ ./script/console
Loading development environment (Rails 2.1.1)
>> Digest::SHA2.hexdigest('foo')
Illegal instruction
On the server that is not crashing:
hostname#node2:~/appname$ cat /etc/issue
Debian GNU/Linux 6.0 \n \l
hostname#node2:~/appname$ uname -a
Linux node2.hostname.org 3.9.3-x86_64-[redacted] #1 SMP Mon May 20 10:22:57 EDT 2013 x86_64 GNU/Linux
hostname#node2:~/appname$ which ruby
/opt/ruby-enterprise-1.8.7-2012.02/bin/ruby
hostname#node2:~/appname$ irb
irb(main):001:0> require 'digest'
=> true
irb(main):002:0> Digest::SHA2.hexdigest('foo')
=> "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae"
irb(main):003:0> exit
hostname#node2:~/appname$ ./script/console
Loading development environment (Rails 2.1.1)
>> Digest::SHA2.hexdigest('foo')
=> "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae"
Related
$ cat /etc/issue
Ubuntu 18.04.6 LTS \n \l
I'm following this Link to install Openstack using Devstack. However git clone https://git.openstack.org/openstack-dev/devstack master branch's ./stack.sh fails with below error.
+./stack.sh:main:230 SUPPORTED_DISTROS='bullseye|focal|f34|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03'
+./stack.sh:main:232 [[ ! bionic =~ bullseye|focal|f34|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03 ]]
WARNING: this script has not been tested on bionic
+./stack.sh:main:234 [[ '' != \y\e\s ]]
+./stack.sh:main:235 die 235 'If you wish to run this script anyway run with FORCE=yes'
+functions-common:die:253 local exitcode=0
+functions-common:die:254 set +o xtrace
[Call Trace]
./stack.sh:235:die
[ERROR] ./stack.sh:235 If you wish to run this script anyway run with FORCE=yes
/opt/stack/devstack/functions-common: line 299: /opt/stack/logs/error.log: No such file or directory
Even ./stack.sh FORCE=yes and stable/newton, stable/pike, stable/victoria & stable/xena branch also results the same above error.
Does the support for Ubuntu 18.04.6 LTS (bionic) deprecated?
Does the support for Ubuntu 18.04.6 LTS (bionic) deprecated?
Not exactly.
As a general rule, the latest version of the script targets the latest supported (by Openstack) versions of the host operating systems. Older versions may work. But there might be minor issues ... that someone with the ability to read / diagnose shell scripts ought to be able to figure out.
If you need a version of the script that explicitly supports (say) Bionic, there will be one in the Git6 repo history.
(This is in line with general OpenStack Ubuntu support. The latest OpenStack release is Wallably and Wallaby no longer supports Bionic. The Bionic -> Focal cross-over release of Openstack was Ussuri; see https://ubuntu.com/openstack/docs/supported-versions. Note that Devstack is not an official OpenStack product, but they are effectively forced to track the "supported release" rules, at least loosely.)
The version of the Devstack script that you checked out does not explicitly supports Focal rather than Bionic.
If you look at https://opendev.org/openstack/devstack/src/branch/master/stack.sh on line 230, it currently says:
# Warn users who aren't on an explicitly supported distro, but allow them to
# override check and attempt installation with ``FORCE=yes ./stack``
SUPPORTED_DISTROS="bullseye|focal|f34|opensuse-15.2|opensuse-tumbleweed|rhel8|rhel9|openEuler-20.03"
If you want a version of devstack that explicitly supports bionic, use git blame (or whatever) to track changes to the SUPPORTED_DISTROS line. You should be able to find some versions where FORCE is not necessary.
On the other hand .... the error message:
/opt/stack/devstack/functions-common: line 299: /opt/stack/logs/error.log:
No such file or directory
implies that the script is assuming that a file or directory already exists. You could probably just create it / them by hand. (It is clearly just a log file / directory.)
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.
trying to install pgbouncer on amazon met this:
[root#somehost ~]# uname -a
Linux somehost 4.4.35-33.55.amzn1.x86_64 #1 SMP Tue Dec 6 20:30:04 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root#somehost ~]# yum install pgbouncer
Loaded plugins: priorities, update-motd, upgrade-helper
No package pgbouncer available.
Error: Nothing to do
Went to github - found only compilable version. Googled and decided to post solution below
at The PostgreSQL Global Development Group repo copy link to your linux release (in my case Amazon Linux AMI 2015.03 - x86_64) and run:
rpm -Uvh https://download.postgresql.org/pub/repos/yum/9.3/redhat/rhel-6-x86_64/pgdg-ami201503-93-9.3-3.noarch.rpm
yum install pgbouncer
as result:
Installed:
pgbouncer.x86_64 0:1.7.2-6.rhel6
solr-5.4.0 version
My Java version
java -version
java version "1.7.0_91"
OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
I did all steps finally am getting this error
sudo service solr status
Found 1 Solr nodes:
Solr process 6003 from /var/solr/solr-8983.pid not found.
How to fix this error?
That Digital Ocean tutorial recommends Java 8 with Solr 5 and provides installation instructions using a PPA. I also found another SO question where switching to Java 8 was the resolution.
I created a fresh Ubuntu 14.04 VM using Vagrant and VirtualBox with these commands...
vagrant init ubuntu/trusty64
vagrant up
Then I followed the tutorial with Solr 5.4.0, and got the same error you did. However, my Solr logs were not deleted, so I was able to find this...
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 402653184 bytes for committing reserved memory.
My Vagrant VM had 512 MB of RAM so I doubled that to 1 GB which is recommended in the tutorial, did a vagrant reload, and Solr started working. Here is my minimal Vagrantfile...
Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.network "private_network", ip: "192.168.33.10"
config.vm.provider "virtualbox" do |vb|
vb.memory = "1024"
end
end
I'm using VirtualBox 5.0.10 and Vagrant 1.8.1. I hope this works for you.
UPDATE: I just went through the tutorial again with a 32-bit Ubuntu 14.04 VM (ubuntu/trusty32 in Vagrantfile) and that also worked. So if you're on a 32-bit host or the 64-bit VM doesn't work for you, the 32-bit VM should work.
I will throw my answer in here just in case someone else spends another hour like I did.
Solr version 6.1.0 + Java 1.7 same error.
I had to upgrade to 1.8. How did I know that was the problem?
:/var/solr/logs# cat solr-8983-console.log
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/eclipse/jetty/start/Main : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:803)
at ....
The 52 version means you need Java 1.8.
Upgrade Ubuntu using
$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install oracle-java8-installer
Credit to this comment.
I recently downloaded Tomcat 7.x as a zip. Running the version.bat gives the following:
c:\apache-tomcat-7.0.19\bin>version
Using CATALINA_BASE: "C:\apache-tomcat-7.0.19"
Using CATALINA_HOME: "c:\apache-tomcat-7.0.19"
Using CATALINA_TMPDIR: "C:\apache-tomcat-7.0.19\temp"
Using JRE_HOME: "C:\Program Files (x86)\Java\jdk1.6.0_29"
Using CLASSPATH: "c:\apache-tomcat-7.0.19\bin\bootstrap.jar;C:\apache-tomcat- 7.0.19\bin\tomcat-juli.jar"
Server version: Apache Tomcat/7.0.19
Server built: Jul 13 2011 11:32:28
Server number: 7.0.19.0
OS Name: Windows Server 2008 R2
OS Version: 6.1
Architecture: x86
JVM Version: 1.6.0_29-b11
JVM Vendor: Sun Microsystems Inc.
Since it's using the 32 bit version of JRE, is it a safe assumption the Tomcat itself is 32-bit?
In the Tomcat bin folder, there is version.bat (version.sh for linux) script. Run it to get version and architecture information. Here is example output for Tomcat 7.062 running 32 bit (x86) on Windows:
C:\KBData\Software\apache-tomcat-7.0.62\bin>version
Using CATALINA_BASE: "C:\KBData\Software\apache-tomcat-7.0.62"
Using CATALINA_HOME: "C:\KBData\Software\apache-tomcat-7.0.62"
Using CATALINA_TMPDIR: "C:\KBData\Software\apache-tomcat-7.0.62\temp"
Using JRE_HOME: "C:\Program Files (x86)\Java\jdk1.7.0_25\"
Using CLASSPATH: "C:\KBData\Software\apache-tomcat-7.0.62\bin\bootstrap.ja
r;C:\KBData\Software\apache-tomcat-7.0.62\bin\tomcat-juli.jar"
Server version: Apache Tomcat/7.0.62
Server built: May 7 2015 17:14:55 UTC
Server number: 7.0.62.0
OS Name: Windows 7
OS Version: 6.1
Architecture: x86
JVM Version: 1.7.0_25-b17
JVM Vendor: Oracle Corporation
The Windows distributions contain executables and a DLL to run Tomcat as a service. You can unzip the download & run Dependency Walker (free) or dumpbin.exe (comes with MS Visual Studio) on the executable to see which processor architecture they support.
See this question for more details: In windows,how do we identify whether a file is 64 bit or 32 bit?
Java programs aren't 32-bit or 64-bit as native programs are. They run in a virtual machine with a standard architecture. Only the JRE, which implements the virtual machine, is 32-bit or 64-bit.