I had issues installing shiny-server in ubuntu 20.04 running on an AWS EC2. Finally i figured out a way to install it from the source. Seems to have installed ok but when i go to https://<xxx>.amazonaws.com:3838/<appname>, it doesn't load up the page. Instead, it gives this error
This site can't be reached.
<xxx>.amazonaws.com took too long to respond.
ERR_CONNECTION_TIMED_OUT
I gave sudo shiny-server and got this
[2021-02-02T17:30:37.418] [INFO] shiny-server - Shiny Server v1.5.16.0 (Node.js v12.20.1)
[2021-02-02T17:30:37.420] [INFO] shiny-server - Using config file "/etc/shiny-server/shiny-server.conf"
[2021-02-02T17:30:37.459] [WARN] shiny-server - Running as root unnecessarily is a security risk! You could be running more securely as non-root.
[2021-02-02T17:30:37.462] [INFO] shiny-server - Starting listener on http://[::]:3838
So that seems to be working fine.
I checked the security groups on EC2 and made sure it allows all inbound connections to port 3838.
Related
I am trying to set up a development environment for Apache/AirFlow on MacBook with macOS 10.14.x.
I have installed docker, virtualbox and created virtual machine and created containers with web_server, worker, scheduler and redis, postgres.
I run :
docker-compose up -d
But, when I visited http://localhost:8080, I got:
This page isn’t working
localhost didn’t send any data.
ERR_EMPTY_RESPONSE
In the docker-compose log file, I found:
[mwebserver_1 [INFO] Parent changed, shutting down: <Worker 34>
[mwebserver_1 [INFO] Worker exiting (pid: 34)
[mwebserver_1 {{cli.py:815}} ERROR - No response from gunicorn master within 120 seconds
[mwebserver_1 {{cli.py:816}} ERROR - Shutting down webserver
I am not sure what the problem could be.
Any suggestions would be appreciated.
After start the docker container's.
Try to run docker exec -it NAME_OF_CONTAINER /bin/bash. After that you're gonna into container bash and you can run airflow webserver.
I am using Kali linux
I am unable to run Apache2, i tried so many ways to fix it .., i successful installed xampp and apache2 but dont know why apache not running, mysql and proFTD is running
When i run code to to check the status of apache in lampp it show that another web server is already running.
(another web server already runing)
write this code in terminal
/opt/lampp/xampp disablessl
then check for the apache
sudo /opt/lampp/xampp start
Starting XAMPP for Linux 7.2.5-0...
XAMPP: Starting Apache...ok.
XAMPP: Starting MySQL...already running.
XAMPP: Starting ProFTPD...already running.
Hi,
We are trying to install CDH cluster on Redhat 7 remote server using cloudera-installer.bin file, in standalone mode( we have only 1 host) . We are specifying hostname/ip address of the machine during installation , it is able to resolve it. But the installation halts during parcel distribution stage. Here are the logs of cloudera-scm-agent :(We tried both cloudera express edition and entrerprise trial version too)
['http://INHUSZ1-V250152:7180/cmf/parcel/download/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel'] location=/opt/cloudera/parcels/.flood/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel progress=0]
[03/Oct/2018 10:11:55 +0000] 28315 Thread-13 downloader INFO Current state: CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel [totalDownloaded=0 totalSize=2120090032 upload=0 state=downloading seed=['http://INHUSZ1-V250152:7180/cmf/parcel/download/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel'] location=/opt/cloudera/parcels/.flood/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel progress=0]
[03/Oct/2018 10:11:57 +0000] 28315 Thread-13 downloader INFO Current state: CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel [totalDownloaded=0 totalSize=2120090032 upload=0 state=downloading seed=['http://INHUSZ1-V250152:7180/cmf/parcel/download/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel'] location=/opt/cloudera/parcels/.flood/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel progress=0]
[03/Oct/2018 10:11:59 +0000] 28315 Thread-13 downloader INFO Current state: CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel [totalDownloaded=0 totalSize=2120090032 upload=0 state=downloading seed=['http://INHUSZ1-V250152:7180/cmf/parcel/download/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel'] location=/opt/cloudera/parcels/.flood/CDH-5.15.1-1.cdh5.15.1.p0.4-el7.parcel progress=0]
Please let us know what can be done
I just had the same error message and stall during install at parcel distribution stage.
Installing a single node (test) cluster on CentOS 7.5 with CDH Express 5.15.
Solution that worked for me was adding the node IP and FQDN to /etc/hosts (previously it only contained entries for 127.0.0.1 localhost):
[root#mynode ~]# vi /etc/hosts
192.168.1.1 myhostname.mydomain
Then restarted Cloudera SCM Agent:
[root#mynode ~]# service cloudera-scm-agent restart
Installation then continued successfully.
Do the following:
Stop all services.
Deactivate all in-use parcels.
Shut down the Cloudera Manager Agent on all hosts.
Move the existing parcels to the new location.
Configure the host parcel directory.
Start the Cloudera Manager Agents.
Activate the parcels.
Start all services.
Delete the corresponding parcels package from below folder including .torrent file
/opt/cloudera/parcels/.flood/
Download and distribute
This is happening because .torrent file is corrupted
I'm working on a fresh installation of stock DSpace 5.3 (Windows Server 2012, Tomcat 8.0, Maven 3.2.5, Ant 1.9.6). This particular instance will be a dark archive without Google Analytics enabled; we don't currently have a GA account or analytics key, although we plan to register one eventually for a separate public-facing instance.
As per the problem described in JIRA ticket DS-2718, DSpace hangs with the following message in dspace.log when I attempt to download a bitstream:
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# I/O exception (java.net.SocketException) caught when processing
request to {s}->https://www.google-analytics.com:443: Network is
unreachable: connect
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# Retrying request to {s}->https://www.google-analytics.com:443
Since we won't be using GA on this instance, disabling it in Spring is a good workaround until the issue is resolved. As per the instructions, I commented out the Google Analytics entry in dspace-5.3-src-release\dspace-xmlui\src\main\webapp\WEB-INF\spring\applicationContext.xml, disabled Tomcat and rebuilt DSpace. An initial attempt running mvn package -Dmirage2.on=true still produced the problem, so I tried a "ground up" rebuild:
cd d:\dspace-5.3-src-release\dspace
mvn clean package -U -Dmirage2.on=true
[successful build]
cd d:\dspace-5.3-src-release\dspace\target\dspace-installer
ant update
[successful update]
[copy webapps to Tomcat 8.0\webapps and start Tomcat]
Even after the rebuild, however, I'm still getting the same error, with the same java.net.SocketException in dspace.log.
Not sure why this isn't working. Have I missed a step or setting in the rebuild process so that the change to applicationContext.xml isn't being applied?
FWIW, I tried grepping for "google" in dspace-5.3-src-release\dspace-xmlui-mirage2 to see if this could be a Mirage 2 problem, but I don't see anything that looks relevant.
This isn't an answer to why you're still seeing the SocketException, but the real fix for the problem you're describing is to remove the default GA key from dspace-services/src/main/resources/config/dspace-defaults.cfg, see https://github.com/DSpace/DSpace/commit/5b84fef1ad789443d06c338558a92f854b20c8ef. Have you tried doing that?
The issue resolved itself after I ran mvn clean -Dmirage2.on=true in both [dspace-src] and [dspace-src]\dspace. I'm guessing that the issue originated on our end due to someone running a maven build from the wrong directory.
I've also removed the default key from dspace-defaults.cfg as suggested. Everything's now working.
As of last night all our new docker deployments started failing because the latest version of docker (docker-1.3.2-1.0.amzn1.x86_64) in the amazon repo fails to start up.
Steps to reproduce are:
## Launch instance with default amazon AMI
yum install docker-1.3.2-1.0.amzn1.x86_64
service docker restart
### Get the following error in /var/log/docker
2014/11/26 05:14:16 docker daemon: 1.3.2 c78088f/1.3.2; execdriver: native; graphdriver:
[8f6d7cfb] +job serveapi(unix:///var/run/docker.sock)
[info] Listening for HTTP on unix (/var/run/docker.sock)
docker: relocation error: docker: symbol dm_task_get_info_with_deferred_remove,
version Base not defined in file libdevmapper.so.1.02 with link time reference
If I downgrade back to docker-1.3.1-1.0.amzn1.x86_64 everything seems to be fine.
Is the AWS package actually broken, or is it just our setup?
Is there a work around other than downgrading?
Yes, it is broken for me too.
Downgrading has been the solution yet.
The same error was by me on a centos VM provisioned at my workplace - a yum update resolved it.
I suspect a build was broken but went out, and has been fixed subsequently.