I am getting the below error-:
[ 698.855708] cloud-init[1158]: 2017-10-09 23:48:42,438 - util.py[WARNING]: Broken config drive: /dev/sr0
I am trying to run the cloud-init during boot of VM and to take the iso from cdrom. Its a centos m/c.
Also this error-:
Also this error-:[ 846.922986] cloud-init[1158]: 2017-10-09 23:51:10,627 - DataSourceEc2.py[CRITICAL]: Giving up on md from ['http://169.254.169.254/2009-04-04/meta-data/instance-id'] after 125 seconds
[ 847.834620] cloud-init[1158]: 2017-10-09 23:51:10,912 - util.py[WARNING]: Getting data from failed
[ 995.764648] cloud-init[3092]: Cloud-init v. 0.7.5 running 'modules:config' at Tue, 10 Oct 2017 03:53:12 +0000. Up 969.10 seconds.
[ 1080.429808] cloud-init[3507]: Cloud-init v. 0.7.5 running 'modules:final' at Tue, 10 Oct 2017 03:54:49 +0000. Up 1065.33 seconds.
ci-info: no authorized ssh keys fingerprints found for user centos.
PLease suggest.
Above error most likely appears when you have malformed meta_data.json or wrong parameter(s) defined in meta_data.json
See error checking test in cloud-init source:
https://github.com/racker/cloud-init-debian-pkg/blob/409f73b8434717b6a2f0353c605399dde35d1f66/tests/unittests/test_datasource/test_configdrive.py
Check out the test test_seed_dir_bad_json_metadata().
Related
As title, I want to know the NebulaGraph Database version.
I use nebula-console here.
[root]# ./nebula-console -addr 192.168.8.136 -port 9669 -u root -p nebula
Welcome to Nebula Graph!
(root#nebula) [(none)]> use basketballplayer
Execution succeeded (time spent 2206/2702 us)
Mon, 12 Dec 2022 06:09:16 UTC
As NebulaGraph is distributed, thus there is technically no version for the "database" but for each component, we could use SHOW HOSTS <type_of_the_process> to get this info since 2.x from the client side:
SHOW HOSTS STORAGE
SHOW HOSTS GRAPH
SHOW HOSTS META
SHOW HOSTS AGENT
There will be a version column of the output then.
Of course, from the server side, the binary itself supports checking the version like this:
/usr/local/nebula/bin/nebula-graphd --version
nebula-graphd version 2022.03.30-nightly, Git: 1e68162, Build Time: Mar 31 2022 02:31:25
This source code is licensed under Apache 2.0 License.
When I run commands in the Windows CMD terminal I see a lot of tracing information.
I have not specifically done anything to enable it.
After some commands (not all) - for example, dotnet. I get this message
Tracing enabled # Tue Mar 30 16:34:45 2021 GMT
--- Invoked dotnet [version: 5.0.4, commit hash: f27d33729518f5aa478aa818b7b4f54a4d50bef1] main = {
C:\Program Files\dotnet\dotnet.exe
}
for PowerShell I see similar
Tracing enabled # Tue Mar 30 15:29:02 2021 GMT
--- Invoked apphost [version: 5.0.4, commit hash: f27d33729518f5aa478aa818b7b4f54a4d50bef1] main = {
C:\Program Files\PowerShell\7\pwsh.exe
-WorkingDirectory
~
}
the question is how to disable this.
The solution is to change environment variable
COREHOST_TRACE=0
Not sure how it was changed on my computer :(.
Since upgrading to 6.8.7 using the rpm on RHEL 7, using systemctl start artifactory fails
Looking in the log its failing at this point
2019-03-16 09:50:28,952 [art-init] [INFO ] (o.a.s.a.ArtifactoryAccessClientConfigStore:593) - Using Access Server URL: http://localhost:8040/access (bundled) source: detected
2019-03-16 09:50:29,379 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:353) - Waiting for access server...
2019-03-16 09:50:30,625 [art-init] [WARN ] (o.j.a.c.AccessClientHttpException:41) - Unrecognized ErrorsModel by Access. Original message: Failed on executing /api/v1/system/ping, with response: Not Found
2019-03-16 09:50:30,634 [art-init] [ERROR] (o.a.s.a.AccessServiceImpl:364) - Could not ping access server: {}
org.jfrog.access.client.AccessClientHttpException: HTTP response status 404:Failed on executing /api/v1/system/ping, with response: Not Found
Previously we would get
2019-03-13 09:56:06,293 [art-init] [INFO ] (o.a.s.a.ArtifactoryAccessClientConfigStore:593) - Using Access Server URL: http://localhost:8040/access (bundled) source: detected
2019-03-13 09:56:06,787 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:353) - Waiting for access server...
2019-03-13 09:56:24,068 [art-init] [INFO ] (o.a.s.a.AccessServiceImpl:360) - Got response from Access server after 17280 ms, continuing.
Any suggestions on debugging whether this access server has started ?
Further to this I found logs showing when it worked it used to start a jar file
2019-03-08 09:19:11,609 [localhost-startStop-2] [INFO ] (o.j.a.AccessApplication:48) - Starting AccessApplication v4.1.48 on hostname.nexor.co.uk with PID 5913 (/opt/jfrog/artifactory/tomcat/webapps/access/WEB-INF/lib/access-application-4.1.48.jar started by artifactory in /)
Now when i look I find /opt/jfrog/artifactory/tomcat/webapps/access/ is empty so there is no jar file to run
The rpm did deliver an access.war file and that is there
$ ls -l /opt/jfrog/artifactory/webapps
total 104692
-rwxrwxr-x. 1 root root 51099759 Mar 14 12:14 access.war
-rwxrwxr-x. 1 root root 56099348 Mar 14 12:14 artifactory.war
Is there some manual step I can run to expand this war file to get the jar (as you can guess I am not up on my java apps)
Eventually got it working by deleting the empty /opt/jfrog/artifactory/tomcat/webapps/access directory and a new one containing the required jar files got created.
Not sure why this happened but that got it working for me
I had similar problem on CentOS 7, the solution was downgrade the newly updated java packages by running this command:
yum downgrade java-1.8.0*
After that restart the artifactory:
systemctl restart artifactory
Try changing the port number under your tomcat\conf\server.xml from 8081 to a different, unused port. Then, restart the Artifactory service to ensure the change takes effect.
I'm trying to work through the manual installation guide. When I get as far as registering an admin account for the console (euare-accountcreate) or registering services (euserv-register-service) the eucalyptus-cloud service inconsistently crashes with the same JVM memory error. As an example a few times I've been able to register the UFS or create the admin account but when I move on to perform another step in the install it will fail and checking the service status shows that it has crashed. I don't have experience with Java memory errors and could really use some help understanding whats going on and how to investigate this type of error in general:
[root#cloud ~]# euserv-describe-services ufs-10.0.0.2
euserv-describe-services: error: connection error (('Connection
aborted.', BadStatusLine("''",)))
[root#cloud ~]# systemctl status eucalyptus-cloud -l
● eucalyptus-cloud.service - Eucalyptus cloud web services
Loaded: loaded (/usr/lib/systemd/system/eucalyptus-cloud.service;
enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2018-10-10 08:45:09 EDT;
4s ago
Process: 45951 ExecStart=/usr/sbin/eucalyptus-cloud $CLOUD_OPTS
(code=exited, status=1/FAILURE)
Main PID: 45951 (code=exited, status=1/FAILURE)
CGroup: /system.slice/eucalyptus-cloud.service
├─46206 /usr/bin/postgres -D /var/lib/eucalyptus/db/data -
h0.0.0.0 -p8777
├─46207 postgres: logger process
├─46209 postgres: checkpointer process
├─46210 postgres: writer process
├─46211 postgres: wal writer process
├─46212 postgres: autovacuum launcher process
└─46213 postgres: stats collector process
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: OpenJDK 64-Bit Server VM
warning: INFO: os::commit_memory(0x00007f496534b000, 12288, 0) failed;
error='Cannot allocate memory' (errno=12)
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: #
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: # There is insufficient
memory for the Java Runtime Environment to continue.
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: # Native memory
allocation (mmap) failed to map 12288 bytes for committing reserved
memory.
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: # An error report file
with more information is saved as:
Oct 10 08:45:08 cloud eucalyptus-cloud[45951]: #
/tmp/hs_err_pid45954.log
Oct 10 08:45:09 cloud eucalyptus-cloud[45951]: 2018-10-10 08:45:09
45951 ERROR 0574 Service exit with a return value of 1.
Oct 10 08:45:09 cloud systemd[1]: eucalyptus-cloud.service: main
process exited, code=exited, status=1/FAILURE
Oct 10 08:45:09 cloud systemd[1]: Unit eucalyptus-cloud.service
entered failed state.
Oct 10 08:45:09 cloud systemd[1]: eucalyptus-cloud.service failed.
Edit to include some version info:
[root#cloud ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (Core)
[root#cloud ~]# java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
EDIT to note my point of confusion: This system only has 25G of RAM in use and 223G free. So I need help understanding how java is running out of memory.
try this fix:
echo 1999999 > /proc/sys/vm/max_map_count
I've encountered a problem with deploying my shiny app on linux Ubuntu 16.04 LTS.
After I run sudo systemctl start shiny-server, and open up my browser heading to http://192.168..*:3838/StockVis/, the web page greys out in a second.
I found some warnings in the web console as below, and survey some information on the web for like two weeks, but still have no solution. :(
***"Thu Feb 16 2017 12:20:49 GMT+0800 (CST) [INF]: Connection opened. http://192.168.**.***:3838/StockVis/"
Thu Feb 16 2017 12:20:49 GMT+0800 (CST) [DBG]: Open channel 0
The application unexpectedly exited.
Diagnostic information is private. Please ask your system admin for permission if you need to check the R logs.
**Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [INF]: Connection closed. Info: {"type":"close","code":4503,"reason":"The application unexpectedly exited","wasClean":true}
Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [DBG]: SockJS connection closed
Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [DBG]: Channel 0 is closed
Thu Feb 16 2017 12:20:50 GMT+0800 (CST) [DBG]: Removed channel 0, 0 left*****
Please kindly give some suggestions to move on.
This can indicate something in your R code is causing an error. As that R error could be anything, this answer is to help you gather that info. The browser console messages will not tell you what that is. In order to access the error, you need to configure Shiny to not delete the log upon exiting the application.
Assuming you have sudo access:
$ sudo vi /etc/shiny-server/shiny-server.conf
Place the following line in the file after run_as shiny; :
preserve_logs true;
Restart shiny:
sudo systemctl restart shiny-server
Reload your Shiny app.
In the var/log/shiny-sever/ directory there will be a log file with your application name. Viewing that file will give you more information on what is going on.
Warning. After you are done, take out the preserve_logs true; line in the conf file and restart Shiny. If not, you will start generating a bunch of log files you don't want.