I am trying to update sonarqube from 7.9 to 8.9.
After installing the new version, in the logs, I had an error in the logs:
java.lang.RuntimeException: can not run elasticsearch as root
So I modified sonar.sh with RUN_AS_USER=sonar
I have make a chown and a chgrp for the sonar user on opt/sonarqube
I try to restart sonarqube with /opt/sonarqube/bin/linux-x86-64/sonar.sh start, in the log I have the followinf error:
2022.07.08 09:24:14 ERROR app[][o.s.a.ProcessLauncherImpl] Failed to create temporary configuration directory [/opt/sonarqube/temp/conf/es]
2022.07.08 09:24:14 ERROR app[][o.s.a.p.ManagedProcessHandler] Fail to launch process [es]
Yet the rights are still good on the server.
Any ideas please?
Thank you,
Related
I keep getting this error on localhost:9000 when running sonarqube community on my machine: The connection to SonarQube is lost. Please contact your system administrator after running brew service start sonarqube. I have never ran sonarqube on this machine nor have I configured anything.
Could this be a misconfiguration or is this out of my hands?
Thanks
Hope everyone is keeping safe!
I have a Ruby on Rails application hosted on AWS Beanstalk. I am using CloudFormation template, to update any stack for e.g., Ruby version, Linux Platform upgrade etc.
I was trying to upgrade, Linux box to 2.11.7 and Ruby to 2.6.6 and then ElasticSearch to 7.4
I was doing these changes in CloudFormation YML template and then I ran aws cloudformation update-stack command to apply these changes.
While the changes took time, I accidentally clicked on Rebuild Environment from Web AWS Console as a result, all the previously configured settings like SQS, Load balancer etc., were replaced by new settings.
Now, whenever I am trying to execute the update-stack command, it fails with below errors:
2020-06-09 15:25:44 UTC+0530
WARN
Environment health has transitioned from Info to Degraded. Command failed on all instances.
Incorrect application version found on all instances. Expected version "code-pipeline-xxxxxxxxxx" (deployment 2377). Application update failed 40 seconds ago and took 79 seconds.
2020-06-09 15:25:03 UTC+0530
INFO
The environment was reverted to the previous configuration setting.
2020-06-09 15:24:44 UTC+0530
INFO
Environment health has transitioned from Ok to Info. Application update in progress on 1 instance. 0 out of 1 instance completed (running for 39 seconds).
2020-06-09 15:24:30 UTC+0530
ERROR
During an aborted deployment, some instances may have deployed the new application version.
To ensure all instances are running the same version, re-deploy the appropriate application version.
2020-06-09 15:24:30 UTC+0530
ERROR
Failed to deploy application.
2020-06-09 15:24:30 UTC+0530
ERROR
Unsuccessful command execution on instance id(s) 'i-xxxxxxxxxx'. Aborting the operation.
2020-06-09 15:24:30 UTC+0530
INFO
Command execution completed on all instances. Summary: [Successful: 0, Failed: 1].
2020-06-09 15:24:30 UTC+0530
ERROR
[Instance: i-xxxxxxxxxx] Command failed on instance. Return code: 18 Output: (TRUNCATED)...g: the running version of Bundler (1.16.0) is older than the version that created the lockfile (1.17.3). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`. Your Ruby version is 2.6.6, but your Gemfile specified 2.6.5. Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/10_bundle_install.sh failed. For more detail, check /var/log/eb-activity.log using console or EB CLI.
2020-06-09 15:24:19 UTC+0530
INFO
Deploying new version to instance(s).
2020-06-09 15:23:45 UTC+0530
INFO
Updating environment developWeb's configuration settings.
2020-06-09 15:23:36 UTC+0530
INFO
Environment update is starting.
I can confirm that I have Ruby-2.6.6 set. I am not sure from where it is picking up the old version of Ruby?
Is there any way I can fix this? OR forcefully apply template changes?
Any help on this would be highly appreciated.
[UPDATE]: When I try to connect to ElasticSearch from Rails console, I get:
Faraday::ConnectionFailed: Failed to open TCP connection to old-elasticsearch-host-name.es.amazonaws.com:80 (Hostname not known: old-elasticsearch-host-name.es.amazonaws.com)
from /opt/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/http.rb:949:in `rescue in block in connect'
Caused by SocketError: Failed to open TCP connection to old-elasticsearch-host-name.es.amazonaws.com:80 (Hostname not known: old-elasticsearch-host-name.es.amazonaws.com)
from /opt/rubies/ruby-2.6.6/lib/ruby/2.6.0/net/http.rb:949:in `rescue in block in connect'
Caused by Resolv::ResolvError: no address for old-elasticsearch-host-name.es.amazonaws.com
from /opt/rubies/ruby-2.6.6/lib/ruby/2.6.0/resolv.rb:94:in `getaddress'
The new URL of elasticsearch instance is different but it is still picking up the old URL from ELASTICSEARCH_HOST ENV variable.
Information from my CF template:
I can now provide info as per request. please tag me to see what I have in CF template
This was a config issue.
Whenever I was running aws update-stack command, it was going to s3 and pulling the zip (of the source code) code and in Gemfile of that zip code ruby version was set to 2.6.5.
So, I'd uploaded the fresh copy of the source code and then executed the update-stack command and it worked
I have an issue where my most recent CodeDeploy failed due to a timeout and am now not able to connect or load my EC2 instance. It didn't rollback to the previous working version and since I can't connect I can't take a deeper look at the CodeDeploy logs. When looking at the log tail there isn't anything glaring about the error log and I don't think it is related to the timeout error, but I'm not sure what in my shell script could be creating the timeout. Any ideas of what might be wrong in my setup? Should I do a check for a node_modules folder before running sudo npm install?
Error:
Error Code: ScriptTimedOut
Script Name:scripts/npm-install.sh
Message: Script at specified location: scripts/npm-install.sh failed to complete in 300 seconds
Log Tail:
LifecycleEvent - AfterInstall
Script - scripts/npm-install.sh
[stderr]npm WARN deprecated lodash-node#3.10.2: This package is discontinued. Use lodash#^4.0.0.
[stderr]npm WARN deprecated sendgrid#4.10.0: Please see v6.X+ at https://www.npmjs.com/org/sendgrid
[stderr]npm WARN deprecated nodemailer#2.7.2: All versions below 4.0.1 of Nodemailer are deprecated. See https://nodemailer.com/status/
[stderr]npm WARN deprecated mailcomposer#4.0.1: This project is unmaintained
[stderr]npm WARN deprecated socks#1.1.9: If using 2.x branch, please upgrade to at least 2.1.6 to avoid a serious bug with socket data flow and an import issue introduced in 2.1.0
[stderr]npm WARN deprecated buildmail#4.0.1: This project is unmaintained
[stderr]npm WARN deprecated sendgrid#1.9.2: Please see v6.X+ at https://www.npmjs.com/org/sendgrid
[stderr]npm WARN deprecated mailparser#0.6.2: This project is unmaintained
[stderr]npm WARN deprecated mimelib#0.3.1: This project is unmaintained
[stderr]
Here is my appspec.yml:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/app/
hooks:
AfterInstall:
- location: scripts/npm-install.sh
runas: ec2-user
timeout: 300
ApplicationStart:
- location: scripts/npm-start.sh
runas: ec2-user
timeout: 60
npm-install.sh:
#!/bin/bash
source /home/ec2-user/.bash_profile
cd /var/www/app
sudo npm install
npm-start.sh:
#!/bin/bash
source /home/ec2-user/.bash_profile
cd /var/www/app
npm start
As you probably know, the 300 second timeout is configured in your appspec.yml file. I'm assuming that npm install should finish in less than 300 seconds.
With the information provided, it's impossible to know what went wrong. Per your concern about the node_modules directory not existing, it won't matter because npm install will create that directory if it doesn't already exist. If possible, I would strongly suggest upgrading the deprecated packages. It's possible NPM is not happy about that.
As for your instance, there is nothing in the scripts that you've provided that should kill your instance. If you can't connect to your EC2 instance, you'll probably want to recycle it and get a new one. If you have something actually running on the EC2 instance you can't connect to, you could create a new CodeDeploy deployment group with the new instance, deploy the code and see if the instance remains healthy. This could be an intermittent oddity, and it would be more valuable to troubleshoot if the issue becomes repeatable.
I have attempted to upgrade our SonarQube instance from 4.5.7 LTS to 5.6.5 LTS. I followed the provided SonarQube upgrade documentation. After browsing to [sonarserver]:9000/setup and ran the DB Upgrade. The upgrade ran a little over 2 hours and came back with this message:
Upgrade Failed
Database connection cannot be established. Please check database status and JDBC settings.
When viewing the log, I see this error:
2017.02.16 13:18:43 ERROR web[o.s.s.d.m.DatabaseMigrator] Fail to execute database migration: org.sonar.db.version.v50.FeedFileSources
java.lang.IllegalStateException: Error during processing of row: [uuid=AVpHrbhU29-XDi5QdhtN,uuid=AVpHrbk629-XDi5Qdh0r,data=using System;
I have copied the entire db upgrade log here: http://pastebin.com/p9CkYhrU
I also tried to restart SonarQube and attempt the db upgrade again, but it ran for 5-10 mins and reported the same result.
Additional Details:
Current SonarQube: 4.5.7 LTS
New SonarQube: 5.6.5 LTS
DB: MySQL 5.7.17
Operating System: Windows Server 2012 R2
After the unsuccessful upgrade, we reverted back to 4.5.7 successfully.
We also previously upgraded from 4.3.1 to 4.5.7 LTS. During this upgrade, we moved our SonarQube database from MySQL 5.5 to 5.7.17 and then upgraded SonarQube to 4.5.7 LTS. The upgrade step for this ran two hours and completed successfully.
Thank you for any assistance,
-Eddie
UPDATE 2/21/17
I stood up a test instance for this SonarQube upgrade on a different server. I installed MySQL 5.7 and SonarQube 4.5.7 LTS using the same backup data. During the upgrade to SonarQube 5.6.5 LTS, I received the same error as before. So I knew at this point that I could duplicate the error. I decided to look at that error message again and found these a bit further down:
Caused by: java.sql.BatchUpdateException: Packet for query is too large (6371233 > 4194304). You can change this value on the server by setting the max_allowed_packet' variable.
Caused by: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (6371233 > 4194304). You can change this value on the server by setting the `max_allowed_packet` variable.
So I went ahead and edited the max_allowed_packet variable in my.ini. First I changed it from 4M to 8M and received a similar error. Next, I changed the variable to 16M and the upgrade got past the error!
Unfortunately, the DB Upgrade ran for 11 more hours and came back with another error:
2017.02.21 02:48:13 ERROR web[o.s.s.d.m.DatabaseMigrator] Fail to execute database migration: org.sonar.db.version.v564.CleanUsurperRootComponents
java.lang.IllegalStateException: Error during processing of row: [id=62566,uuid=AVpc2I0gt4GsKrhSYYYQ]
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Application was streaming results when the connection failed. Consider raising value of 'net_write_timeout' on the server.
Caused by: java.net.SocketException: Connection reset
I increased the net_read_timeout in mysql from 60 to 1200. set net_write_timeout = 1200; I restarted SonarQube, ran the DB Upgrade again, and got past the error. The upgrade continued running and I received another error:
2017.02.21 09:57:05 ERROR web[o.s.s.d.m.PlatformDatabaseMigration] DB Migration or container restart failed. Process ended with an exception java.lang.IllegalStateException: Fail to load plugin Clirr [clirr]
Caused by: java.lang.NoClassDefFoundError: org/sonar/api/batch/maven/DependsUponMavenPlugin
Caused by: java.lang.ClassNotFoundException: org.sonar.api.batch.maven.DependsUponMavenPlugin
Looks like a plugin error, so I went ahead and looked into that individual plugin. I found some information about the Clirr plugin being deprecated, so I removed it from the Plugins folder, restarted SonarQube, and got hit with another plugin error (different plugin). I got 6 or 7 of these errors and was able to fix them by either removing or replacing the .jar in the Plugins folder with the newer compatible version.
So after fixing the Java plugin, I restarted SonarQube and it started up fine! I am now running SonarQube 5.6.5 LTS on my sandbox server. The next step will be for me to revert back to 4.5.7 LTS and try the upgrade again to be sure I will have a successful production upgrade in the future.
I am posting to hopefully help others if they run into this issue on Mac. I recently updated ES to 2.2.x branch using Homebrew:
brew uninstall --force elasticsearch
brew update
brew install elasticsearch
I repeatedly got connection errors trying both localhost and 127.0.0.1 on port 9200.
curl http://localhost:9200
curl: (7) Failed to connect to localhost port 9200: Connection refused
I tried an unload and load.
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.elasticsearch.plist
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.elasticsearch.plist
Then tried starting manually.
elasticsearch
The following errors appeared indicating that the Java version 1.7.x was an error and why it would not start.
Exception in thread "main" java.lang.RuntimeException: Java version: Oracle Corporation 1.7.0_45 [Java HotSpot(TM) 64-Bit Server VM 24.45-b08] suffers from critical bug https://bugs.openjdk.java.net/browse/JDK-8024830 which can cause data corruption.
Please upgrade the JVM, see http://www.elastic.co/guide/en/elasticsearch/reference/current/_installation.html for current recommendations.
If you absolutely cannot upgrade, please add -XX:-UseSuperWord to the JAVA_OPTS environment variable.
Upgrading is preferred, this workaround will result in degraded performance.
at org.elasticsearch.bootstrap.JVMCheck.check(JVMCheck.java:123)
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:283)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Refer to the log for complete error details.
After getting past this error, there were errors as well for previously-installed plugins on the 1.7.x branch.
Exception in thread "main" java.lang.IllegalStateException: Could not load plugin descriptor for existing plugin [bigdesk]. Was the plugin built before 2.0?
Likely root cause: java.nio.file.NoSuchFileException: /usr/local/var/lib/elasticsearch/plugins/bigdesk/plugin-descriptor.properties
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
at java.nio.file.Files.newByteChannel(Files.java:315)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:380)
at java.nio.file.Files.newInputStream(Files.java:106)
at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:87)
at org.elasticsearch.plugins.PluginsService.getPluginBundles(PluginsService.java:378)
at org.elasticsearch.plugins.PluginsService.<init>(PluginsService.java:128)
at org.elasticsearch.node.Node.<init>(Node.java:146)
at org.elasticsearch.node.Node.<init>(Node.java:128)
at org.elasticsearch.node.NodeBuilder.build(NodeBuilder.java:145)
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:178)
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:285)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Refer to the log for complete error details.
The solutions to these issues I discovered were the following:
Edit the /usr/local/etc/elasticsearch/elasticsearch.yml file and verify the bind_host configs are commented so it will default to 0.0.0.0.
Edit the /usr/local/Cellar/elasticsearch/YOUR_VERSION/libexec/bin/elasticsearch.in.sh file and add the -XX:-UserSuperWord flag after the other JAVA_OPTS:
JAVA_OPTS="$JAVA_OPTS -XX:-UseSuperWord"
Manually remove the previous plugins so you can install the latest versions for that ES branch:
/usr/local/Cellar/elasticsearch/2.2.0_1/libexec/bin/plugin list
Installed plugins in /usr/local/var/lib/elasticsearch/plugins:
- bigdesk
- head
/usr/local/Cellar/elasticsearch/2.2.0_1/libexec/bin/plugin remove bigdesk
/usr/local/Cellar/elasticsearch/2.2.0_1/libexec/bin/plugin remove head
After these steps I could once again start ES 2.x and then I can re-install any desired plugins. I hope this helps others if they run into similar issues.
I had this issue on MacOs, when I tried to uninstall elasticsearch7 and install elastisearch#6 using homebrew.
I resolved it by manually deleting the following directories and installed elasticsearch#6
Data: /usr/local/var/lib/elasticsearch/
Logs: /usr/local/var/log/elasticsearch/elasticsearch_<<user>>.log
Plugins: /usr/local/var/elasticsearch/plugins/
Config: /usr/local/etc/elasticsearch/
steps:
>brew uninstall elasticsearch
>rm -rf <<above mentioned directories>>
>brew install elasticsearch#6