I am trying to run DotTrace on Linux container.
Placed dotTrace folder in a tmp folder and accessing the command from app folder reference. Below is the command:
./dotTrace.sh start --framework=NetCore /usr/share/dotnet/dotnet /app/Acidaes.CRMnext.UI.Web.dll --timeout=10s --save-to=./snapshots/snapshot.dtp
Everything with setup and paths is correct here.
But, I am getting below error while executing:
warn: Microsoft.AspNetCore.Server.Kestrel[0]
Overriding address(es) 'http://+:80'. Binding to endpoints defined via IConfiguration and/or UseKestrel() instead.
Unhandled exception. System.IO.IOException: Failed to bind to address https://[::]:443: address already in use.
For capture with process ID, command in use is:
/tmp/./dotTrace.sh attach 1 --save-to=./snapshots/snapshot.dtp
And error is:
Unable to start profiling. Connection refused.
Any help or suggestions are greatly welcomed.
/tmp/./dotTrace.sh start --framework=NetCore /usr/share/dotnet/dotnet /app/Acidaes.CRMnext.UI.Web.dll --timeout=10s --save-to=/tmp/./snapshots/snapshot.dtp
Related
while using the command " roslaunch turtlebot3_bringup turtlebot3_robot.launch" for the turtlebot3. I am getting the following error:
RLException: Unable to contact my own server at [http://IP_ADDRESS_OF_RASPBERRY_PI:40449/].
This usually means that the network is not configured properly.
A common cause is that the machine cannot connect to itself. Please check
for errors by running:
ping ip_address_of_raspberry_pi
For more tips, please see
http://wiki.ros.org/ROS/NetworkSetup
The traceback for the exception was written to the log file
I checked ping command and it is connected to TB3
I am having an error while trying to attach to the quorum node, using the following command :--
geth attach --datadir new-node-1/geth.ipc
then I get this error
Unable to attach to remote geth: dial unix new-node-1/geth.ipc: connect: no such file or
directory
I tried to locate path of geth.ipc but nothing was there. I guess the file is not being created.
any suggestions guys..
You should be running the command like this (without --datadir):
geth attach new-node-1/geth.ipc
If that still doesn't work then make sure you have the correct path for the ipc file. Is new-node-1 definitely the same path that was specified to the quorum node when it was started (i.e. with with --datadir new-node-1).
If the path is correct but geth.ipc file doesn't exist then the node hasn't managed to start up. Check the log file to see if there were any errors.
Try out below:
geth attach http://127.0.0.1:8545
It worked for me
When I run vagrant up I get this error
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["startvm", "3ae7b70c-8ea1-417a-ab67-99aef96624f8", "--type", "headless"]
Stderr: VBoxManage.exe: error: Failed to open/create the internal network 'HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2' (VERR_INTNET_FLT_IF_NOT_FOUND).
VBoxManage.exe: error: Failed to attach the network LUN (VERR_INTNET_FLT_IF_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap, interface IConsole
I found the solution here: https://www.howtoforge.com/setup-a-local-wordpress-development-environment-with-vagrant/ which is to update the driver of VirtualBox Host-Only Ethernet Adapter
But the problem is I am remotely connected to the machine. So I am afraid that the network settings may lose my remote connection. Also, I cannot reboot the machine.
Is it safe to follow the steps mentioned in the link above which should not disconnect me? If not, is there any alternative way?
Recently I have struggled with this issue. I tried many times to solve the issue. Sometimes I was able to run my vagrant machines successfully but how I did was not sure because I was trying lot of options. But finally, I found a way to solve it. It's pretty simple and tricky.
Solution:
Once you get this error on your terminal, just open your computer network adaptors from the control panel. Select the adaptor which was created for that virtual box. simply disable once and enable again. then run vagrant up command. That's it. the problem is gone.
- Start --> Network status --> Change adaptor options --> (select the Ethernet adaptor - In my case it is Ethernet4)
- Right click --> Disable and right click --> Enable
- vagrant up
I faced the same issue and could not resolve it by changing properties in Network Adapters.
Then i reinstalled Virtual Machine by below command and it worked fine:
V:\softwares>VirtualBox-6.0.4-128413-Win.exe -msiparams NETWORKTYPE=NDIS5
When I login to the server, but 22 is already open for all upcoming connections still getting error as below,
ssh Server_Name
ssh: connect to host Server-IP port 22: Connection refused
I misleadingly change the the owner of the system and change root privileges with jenkins. So, right now I could not able to log into the system and port 22 is closed it's throwing the error.
I understood the error issue occurred because of wrong fstab file and wrong editing to sshd conf(Not sure). And, the directory of authorized_keys been messed up. I tried this solution but not working
I tried accessing via public DNS, via private IP address, detaching and re-attaching volumes driver after attaching it to other instance(but, once I attached to it, I could not able to ssh into that instance), etc. but no luck. Also, tried login with Jenkins user still not working. But, jenkins is still running fine on the server and I could access the Jenkins Dashboard and run the shell onto my instance. But, if I try any sudo command, it shows sudo: effective uid is not 0, is sudo installed setuid root?
Build step 'Execute shell' marked build as failure
Questions
Is there any way to get back my instance port 22 running fine as before ?
Is there a way I can run the sudo commands using Jenkins user by creating the job(By running the shell) inside Jenkins ?
I could trace on the IP which clearly shows port 22 is closed and I could not do anything because of it. Thanks in advance.
I am attempting to install REDHAWK v1.8.2 on a fresh install of CentOS 6.4 32 bit, but I am unable to get omniNames and omniEvents to start.
sudo /sbin/service omniEvents stop
Stopping CORBA event service: omniEvents
sudo /sbin/service omniNames stop
Stopping omniNames [ OK ]
sudo /sbin/service omniNames start
Starting omniNames [ OK ]
sudo /sbin/service omniEvents start
Starting CORBA event service on port 11169: omniEvents: [25848]: Warning - failed to resolve initial reference 'NameService'. Exception: TRANSIENT
omniEvents.
I tried to verify if omniNames was really running by calling the naming client, but got an error (see below), so it seems omniNames is not successfully starting.
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
As part of the debugging process, I tried to kill the omniNames process and start it a different way (see below).
sudo killall omniNames
omniNames -start
Wed Nov 13 21:08:08 2013:
Starting omniNames for the first time.
Error: cannot create initial log file '/var/omninames/omninames-orion.log':
No such file or directory
You can set the environment variable OMNINAMES_LOGDIR to specify the
directory where the log files are kept.
I'm not sure why omniNames can't create the log file, because I verified that /var/omninames folder actually exists and even starting omniNames as root yields the same error. Regardless, I set the log directory to my desktop to circumvent the error (see below).
export OMNINAMES_LOGDIR=/home/$USER/Desktop/logs
mkdir -p /home/$USER/Desktop/logs
omniNames -start
Wed Nov 13 21:09:17 2013:
Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000001000000000000005c000000010102000a00000031302e322e382e333500f90a0b0000004e616d6553657276696365000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
Even though it looks like omniNames successfully started, when I open another terminal window and call the naming client, I get the same error as before (see below).
nameclt list
Caught a TRANSIENT exception when trying to validate the type of the
NamingContext. Is the naming service running?
The only modification I made in the /etc/omniORB.cfg file is to add the lines for InitRef (see below).
InitRef = NameService=corbaname::localhost
InitRef = EventService=corbaloc::localhost:1169/omniEvents
Also, I am not connected to the internet so my version of CentOS has not been updated from the base version, except for the boost libraries as recommended in Appendix J of the manual (http://sourceforge.net/projects/redhawksdr/files/redhawk-doc/1.9.0/REDHAWK_Manual_v1.9.0.pdf/download).
Looks like the issue is in your configuration. You've got the wrong port in your configuration file. It should be port 11169 however you've listed port 1169.
See: http://redhawksdr.github.io/Documentation/mainch2.html#x4-120002.6 for details.
A few other observations and tricks regarding omniOrb in case this was not the issue.
Sometimes omninames/omnievents can get into a bad state. The fix is to delete the log files created by omniNames and omniEvents and restart the services. They are located:
/var/lib/omniEvents/*
/var/omniNames/*
You'll need to be root to delete those files. I always forget where they are located and often do a "locate omni | grep -i log" to remind myself but you must do this as root since they are not visible to standard users.
While it should not matter, I've personally found that using 127.0.0.1 is more reliable than localhost. For some reason, using localhost within a VM in the configuration file has caused me problems in the past. Consider using 127.0.0.1 instead of localhost. This is what the current version of the Redhawk Manual recommends as well.
You mentioned you are using Redhawk v1.8.2. As an FYI, the latest REDHAWK version in the 1.8 series is currently v1.8.5 and 1.9.0 was also recently released.
Hopefully this gets you up and running!