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 :(.
Related
I upgraded Sonatype Nexus to 3.19.1 from 3.17.1.
Now it wont start and I checked the logs.
Log says " Missing recipe: helm-proxy"
I did setup helm proxy plugin as per link Nexus Helm recipe
Complete log is below.
2019-11-01 15:29:45,358+1100 ERROR [FelixStartLevel] *SYSTEM org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl - Failed transition: NEW -> STARTED
java.lang.IllegalStateException: Missing recipe: helm-proxy
at com.google.common.base.Preconditions.checkState(Preconditions.java:585)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.recipe(RepositoryManagerImpl.java:161)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.newRepository(RepositoryManagerImpl.java:179)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.restoreRepositories(RepositoryManagerImpl.java:271)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.doStart(RepositoryManagerImpl.java:253)
at org.sonatype.nexus.common.stateguard.StateGuardLifecycleSupport.start(StateGuardLifecycleSupport.java:67)
at org.sonatype.nexus.common.stateguard.MethodInvocationAction.run(MethodInvocationAction.java:39)
at org.sonatype.nexus.common.stateguard.StateGuard$TransitionImpl.run(StateGuard.java:193)
at org.sonatype.nexus.common.stateguard.TransitionsInterceptor.invoke(TransitionsInterceptor.java:56)
at org.sonatype.nexus.extender.NexusLifecycleManager.startComponent(NexusLifecycleManager.java:199)
at org.sonatype.nexus.extender.NexusLifecycleManager.to(NexusLifecycleManager.java:111)
at org.sonatype.nexus.extender.NexusContextListener.moveToPhase(NexusContextListener.java:311)
at org.sonatype.nexus.extender.NexusContextListener.frameworkEvent(NexusContextListener.java:208)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1431)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
2019-11-01 15:29:45,379+1100 ERROR [FelixStartLevel] *SYSTEM org.sonatype.nexus.extender.NexusContextListener - Failed to start nexus
java.lang.IllegalStateException: Missing recipe: helm-proxy
at com.google.common.base.Preconditions.checkState(Preconditions.java:585)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.recipe(RepositoryManagerImpl.java:161)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.newRepository(RepositoryManagerImpl.java:179)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.restoreRepositories(RepositoryManagerImpl.java:271)
at org.sonatype.nexus.repository.manager.internal.RepositoryManagerImpl.doStart(RepositoryManagerImpl.java:253)
at org.sonatype.nexus.common.stateguard.StateGuardLifecycleSupport.start(StateGuardLifecycleSupport.java:67)
at org.sonatype.nexus.common.stateguard.MethodInvocationAction.run(MethodInvocationAction.java:39)
at org.sonatype.nexus.common.stateguard.StateGuard$TransitionImpl.run(StateGuard.java:193)
at org.sonatype.nexus.common.stateguard.TransitionsInterceptor.invoke(TransitionsInterceptor.java:56)
at org.sonatype.nexus.extender.NexusLifecycleManager.startComponent(NexusLifecycleManager.java:199)
at org.sonatype.nexus.extender.NexusLifecycleManager.to(NexusLifecycleManager.java:111)
at org.sonatype.nexus.extender.NexusContextListener.moveToPhase(NexusContextListener.java:311)
at org.sonatype.nexus.extender.NexusContextListener.frameworkEvent(NexusContextListener.java:208)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1431)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
Any idea whats going wrong.
If I choose a new empty data directory, Nexus starts. But I will lose my existing data.
Update
I was able to bring it up. Downloaded a fresh copy of nexus-repository-helm-0.0.12.jar file and nexus is back online.
However I still can't bring it up as a service. I have to execute nexus/bin/nexus start to get it up. No logs in nexus.log as well.
Log from journal -xe
Nov 01 16:54:29 lndevopsnx polkitd[867]: Unregistered Authentication Agent for unix-process:6536:123145 (system bus name :1.60, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Nov 01 16:54:29 lndevopsnx systemd[1]: Started nexus service.
-- Subject: Unit nexus.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nexus.service has finished starting up.
--
-- The start-up result is done.
Nov 01 16:54:29 lndevopsnx systemd[1]: nexus.service: main process exited, code=exited, status=255/n/a
Nov 01 16:54:30 lnpdevopsnx nexus[6732]: Shutting down nexus
Nov 01 16:54:30 lndevopsnx nexus[6732]: nexus is not running.
Nov 01 16:54:30 lndevopsnx systemd[1]: Unit nexus.service entered failed state.
I was able to bring it up. Downloaded a fresh copy of nexus-repository-helm-0.0.12.jar file and nexus is back online. However I still can't bring it up as a service. I have to execute nexus/bin/nexus start to get it up.
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().
I have created a simple Qt console application (dbus service) and I need to launch it using systemd.
However every time I execute systemctl start my_serv it fails to start the application and I end up having log in journalctl -xe indicating that application has failed to load libQt5Gui.so.5 (i'm pretty sure it is not related to this particular library):
raspberrypi systemd[1]: Started my_serv.service.
raspberrypi MyService[2812]: /opt/services/MyService: error while loading shared libraries: libQt5Gui.so.5: cannot open shared object file: No such file or directory
raspberrypi systemd[1]: my_serv.service: main process exited, code=exited, status=127/n/a
raspberrypi systemd[1]: Unit my_serv.service entered failed state.
From the other hand application launches fine when I do this from console under root user (i.e. it fails to register an object on dbus, but I think it is not relevant):
./MyService
WELCOME FROM MY SERVICE
Object was registered on dbus
Service was not registered on dbus
Qt libraries are locates by the following path:
ls -al /usr/local/qt5/lib/libQt5Gui.*
-rwxrwxrwx /usr/local/qt5/lib/libQt5Gui.la
-rwxrwxrwx /usr/local/qt5/lib/libQt5Gui.prl
lrwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so -> libQt5Gui.so.5.9.1
lrwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so.5 -> libQt5Gui.so.5.9.1
lrwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so.5.9 -> libQt5Gui.so.5.9.1
-rwxrwxrwx /usr/local/qt5/lib/libQt5Gui.so.5.9.1
It seems that everything is fine with links to libraries in the binary. The ldd output is as follows:
ldd MyService
libQt5Gui.so.5 => /usr/local/qt5/lib/libQt5Gui.so.5 (0x76a92000)
libQt5DBus.so.5 => /usr/local/qt5/lib/libQt5DBus.so.5 (0x76a0d000)
libQt5Core.so.5 => /usr/local/qt5/lib/libQt5Core.so.5 (0x7654e000)
The service file looks like this (/etc/systemd/system/my_serv.service)
[Service]
ExecStart=/opt/services/MyService
User=root
Most probably the linker directories are not known in the context of systemctl. Try setting the environment variable LD_LIBRARY_PATH to the relevant dirs at the start of your service script; see man ld.so for details. Or look at other service scripts on your system to get an idea how the environment is correctly set there.
You can check /etc/ld.so.conf file, example the content is include ld.so.conf.d/.conf.So,you can type a new file under /etc/ld.so.conf.d/ , and put your base path of libQt.so to the file . exmaple:usr/local/qt5/lib/.
And last, execute ldconfig.
I'm running Docker on CentOS 7, from time to time there's the following message displayed:
Message from syslogd#dev-master at Mar 29 17:23:03 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
I've googled a lot, read a lot of resources found and tried many ways like keeping my system updated, upgrading kernel etc, but the message still keeps showing up, it's not too often but sooner or later I'll see it. Also I found issue for this problem on docker github is still open, then my questions are:
What does this message mean? Could somebody give me a simple explanation why docker causes it?
Is there any workaround for this?
If it could not be fixed yet(the issue is still open), will it affect the server or services running inside docker container? Will it be a serious performance issue because it also happens on our production servers?
Docker version:
Client:
Version: 1.11.1
API version: 1.23
Go version: go1.5.4
Git commit: 5604cbe
Built: Wed Apr 27 00:34:42 2016
OS/Arch: linux/amd64
Server:
Version: 1.11.1
API version: 1.23
Go version: go1.5.4
Git commit: 5604cbe
Built: Wed Apr 27 00:34:42 2016
OS/Arch: linux/amd64
OS info:
CentOS 7, with kernel version: 4.6.0-1.el7.elrepo.x86_64
I really appreciate for any info/tips or resources, thanks a lot.
Your best source of information is the issue you linked to docker#5618. This is a kernel bug, and has not yet been resolved. The issue is "triggered" by docker because starting/stopping containers also creates network interfaces for containers when they are created/destroyed.
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.