Grails run-app fails on VM VirtualBox: hangs on build, can't access server - linux

I'm new to Grails and attempting to implement the Hello World app described at grails.org's Getting Started guide.
I have installed Grails using SDKman on an Ubuntu Server 16.04 VM (VirtualBox, running as a service). My host machine is Windows 10.
I configured two network adapters in VirtualBox: the first a NAT with port forwarding (3022 host -> 22 guest, 8080 host -> 8080 guest), the second a Host-Only adapter.
I can SSH into my VM just fine from my Windows host (using Bash): ssh -p 3022 user#localhost
When I run python3 -m http.server 8080 from that SSH session, it successfully listens on both localhost:8080 and :8080. I can access both URLs from a browser on my host machine.
When I run grails run-app it hangs forever, and none of the above endpoints work from my host.
When I run grails run-app --verbose I see it compile without complaint through "Building 85% > :bootRun". I understand that this is expected behavior, but I never see "Application started" or any similar message. It never starts.
ONE TIME the following command succeeded in building and running the app, creating exactly the result I needed:
grails -Dserver.port=8080 -Dserver.host=0.0.0.0 run-app --verbose --stacktrace
However when I stopped the app and tried again, it failed as before.
I notice that VirtualBox > Settings > Network > Adapter #2 which I had set as "Host-Only Network" has multiple times reset itself to Bridged. I suspect that this reset may have caused my problem. But I don't know how to prevent the reset, or to restore that functionality I so briefly had.
Thanks, anyone who can help!

Resolved! Turns out run-app just takes a LONG time to finish compiling and building, upwards of 10 minutes. So I just needed to wait ~5+ minutes with no visual sign of action before the completion message would show and I could access my site. :)

Related

Simple Web Agent - Volttron

I am attempting to launch the Simple Web Agent on the the develop branch using python3 and after having followed the documentation the agent is reportedly running according to "vctl status". However, netstat does not show any process running on the localhost and any attempt to communicate with localhost leads to "localhost refused to connect". Is there some process that must be completed before the documentation (other than activating the platform), or is there some other issue potentially in implementation, or is this a bug.
Screenshot
The SimpleWebAgent runs on top of the volttron platform itself. So you would need to setup the configuration file to support the web itself in the base platform.
# bootstrap the environment
(volttron) ~/volttron: python3 bootstrap.py --web
# create instance capable of handling web
(volttron) ~/volttron: vcfg
# Start volttron
(volttron) ~/volttron: ./start-volttron
Now you can do your netstat test and go from there.

Run a gui based application on a remote Linux machine using telnet

I need to run a gui-based application on a remote PC to which I am connected over telnet. The remote PC runs Linux Ubuntu 18.04
To figure out the screen, I run the following command on the remote machine:
echo $DISPLAY
which gave me :1 as result.
Then I run the program on the remote machine from my client (over telnet) using:
DISPLAY=:1 application_name
The program started correctly (since, in addition to the GUI, it prints some things on the command line) but the GUI didn't show up. But, if I run my app directly on the remote machine, everything is fine.
As a test, I tried to run firefox browser on an another machine (always through telnet) with the following command:
DISPLAY=:0 firefox
and it worked. Note: on the other machine the output of echo $DISPLAY was :0. Furthermore, I could not test my app on the second machine.
It seems that there are different settings between the two machines since what I'm trying to do works on a machine, but not on the other.
Do you have any idea of what type of setting should I check?
Did you try to run your application on the first remote machine but with DISPLAY=:0 instead of :1?
What is the error message you get from application when you started application in the first case ("DISPLAY=:1 app_name").

Remote debugging nodejs app in Intellij with Docker - port already allocated

I want to start debugging node.js app using Intellij and node.js interpreter running on Docker. While running the app works, when I try to debug I get the error:
Error running 'index.js'
com.github.dockerjava.api.exception.InternalServerErrorException:
{"message":"driver failed programming external connectivity on
endpoint focused_poincare
(a17137973880d1be7c6a74fc142184fdda31e0dec8ebd539b09d9dbe4cf70014):
Error starting userland proxy: Bind for 0.0.0.0:55578 failed: port is
already allocated"}
Remote interpreter was configured acccording to the documentation. I have created a new Node.js Run/Debug configuration and entered the following data:
.
What might be the cause for debugging not working?
I use:
Intellij Idea Ultimate v. 2019.1.4 Preview
Intellij NodeJS plugin v. 191.7479.1, NodeJS remote interpreter plugin v. 191.6014.8 and Docker plugin v. 191.7141.44
Docker Desktop Community v. 2.0.0.3
EDIT: Adressing the comments:
Local debugging works. The file (index.js) that I am trying to run consists only of console.log('Hello world!') so I don't spawn any child processes on my own. My host system has Windows 10 Pro as OS, so for checking the open ports on host system I used netstat -an | find "55578", which returned nothing. Moreover, if I try to run docker manually from the command line, using docker run -it -p 55578:55578 node, everything runs and no error is given.
Also, each time I try remote debugging, the port number given by Intellij in an error message seems to be random high port number. I tried looking for open ports just after getting error message, but never found one that is open with a number reported by Intellij and those indeed appear in the output:
My Run/Debug configuration:
My Docker configuration (I had to check "Expose daemon on tcp://localhost:2375 without TLS" in Docker configuration to make Intellij and Docker play together):
EDIT: When I add --inspect-brk=0.0.0.0:55432 as "Node Parameters" in "Run/Debug Configurations" Intellij windows (per this bug report) the container nad program start, but debugging seems to be no-op (e.g. the program does not stop on breakpoints).
After updating to Intellij v. 2019.2 I was able to get the container debugging to work using the workaround already mentioned in my question.
I have added a parameter --inspect-brk=0.0.0.0:55432 to Node parameters option in Run/Debug configuration (see the picture below) and everything seems to be working, including the breakpoints.

Getting "This site can’t be reached" after launching the hub using docker

Below are the steps I followed:
Access Linux server using putty from Windows 7
Run docker run -d -P -p 4545:4444 --name standalone_grid selenium/standalone-chrome on Linux
Launch chrome browser on windows and try to access
http://<linux_server_ip>:4545. Error site can't be reached. This server also has Jenkins installed which can be accessed at http://<linux_server_ip>:8080
How can I fix this? Am I doing anything wrong?
docker ps out put
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
60422c2cd9b1 selenium/standalone-chrome "/opt/bin/entry_poin…" About an hour ago Up About an hour 0.0.0.0:4545->4444/tcp standalone_grid
As mentioned in the comments first thing you want to check if the container is up:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b7a560331584 selenium/standalone-chrome "/opt/bin/entry_poin…" 2 minutes ago Up 2 minutes 0.0.0.0:4545->4444/tcp standalone_grid
Next step would be just to verify locally is it working from the Linux console:
curl http://<linux_server_ip>:4545
If this works you already know it is a networking issue. Please check your local iptables rules:
sudo iptables -L INPUT
to see if there are any restrictions for incoming connections. If this is empty the the issue lays in connectivity within the network itself. You can try to workaround it by using a Putty ssh tunnel.
EDIT:
The issue was related to port 4545, using a different port resolved the problem.

Docker: Error starting userland proxy: Bind for 0.0.0.0:50000: unexpected error Permission denied on Azure VM

I'm new to Docker so please be kind but I am testing it out on a Windows 10 image on Azure (I know I could run it directly but I wanted to try it in a VM first).
I have a fresh Windows 10 image that I have installed Docker for Windows 2.0.0 on.
Note: I did not tick the option to use Windows containers instead of linux containers.
Once it installed (and rebooted) I was prompted to install Hyper-V and Containers features (causing restarts).
Once it was all installed I open an Administrative PowerShell window to download Jenkins:
docker run -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts
This gave me the error:
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: driver failed programming external connectivity on endpoint goofy_lederberg (deaba2deeea0486c92ba8a1a32740295f03859b1b5829d39e39eff0b24613ebf): Error starting userland proxy: Bind for 0.0.0.0:50000: unexpected error Permission denied.
I thought this was strange as 50000 wasn't a port that I expected to be in use, changing this to different ports (50001) produced the same error.
Running:
netstat -a -n -o
Showed that the port was not in use.
If I remove -p 50000:50000 from the command it can bind and start Jenkins but I assume it needs this port mapping to work correctly.
Previous posts have suggested stopping the World Wide Web Publishing service but that isn't installed.
There are no other running Docker containers.
I assume the port is in use or something is stopping the port mapping.
Assuming a user has permission to create a port binding from their terminal are there any other techniques beside netstat to determine if something is bound to a port - either something internal to docker's own checking process or something at the host OS level?
Rather embarrassingly this worked this morning with no changes other than the VM was shutdown over the weekend.
Maybe all it needed was a reboot?

Resources