Today, I was trying to run the web console of airflow port other than 8080 like 80, 8090 but every time I was mentioning a different port in airflow.cfg and re-initialize the airflow and run airflow webserver -D
But every time the web console was running at port 8080 can anyone help or encountered this issue?
You need to change the port on airflow.cfg after you save the file, you shall run airflow db init and start airflow webserver again airflow webserver -D
If you are using docker image that will be different. You need change you docker-compose.yaml file
Related
I cant connect to the webserver after I init my Airflow. These are steps I did:
pip3 install apache-airflow
mkdir ~/airflow
export AIRFLOW_HOME=~/airflow
airflow initdb
airflow webserver -p 8080
Can anyone tell me why it shows as below?
The error Connection in use: ('0.0.0.0', 8080) means that the port is used by another service, and you cannot run your airflow webserver on the same port, so try to use another port:
airflow webserver -p 8088
Then in your browser try with new url
http://localhost:8088/
I am running my code using MPI on a cluster. My code runs as a task in a docker running in swarm mode.
Steps I follow to run my code:
Create a overlay network
Run docker in swarm mode
Start a docker service (replicas = 4) using below command:
docker service create --name mpiser --network mpinet --replicas 4 mpitest:latest
My test code is a simple python script having:
from mpi4py import MPI
import subprocess
import time
comm = MPI.COMM_WORLD
sizeComm = comm.Get_size()
rank = comm.Get_rank()
while True:
print("Rank:",rank,"Hostname:",subprocess.check_output(['hostname']))
time.sleep(2)
I find the ip address of the tasks launched as part of the service
exec into one of the containers
create a "hosts" file with the ip addresses I found
Launch the test code using below command:
mpirun --allow-run-as-root -n 33 --hostfile hosts --mca btl_tcp_if_exclude eth1,lo python3 /home/test.py
This works fine and I can see the prints from all the containers within the swarm.
However, if I expose one of the ports while creating service with below command
docker service create --name mpiser -p 3000:3000 --network mpinet --replicas 4 mpitest:latest
The mpirun command fails with below errors:
------------------------------------------------------------
A process or daemon was unable to complete a TCP connection
to another process:
Local host: 8d3c60280396
Remote host: cc2da25814cc
This is usually caused by a firewall on the remote host. Please
check that any firewall (e.g., iptables) has been disabled and
try again.
------------------------------------------------------------
I tried using --mca btl_tcp_if_include to include only the interface that shows the ip address I added in the hosts file
I tried using --mca btl_tcp_if_exclude to exclued other interfaces that does not have the ip address I added in hosts file
Both these did not help.
Any suggestions on why exposing the port causes communication issue between the containers will be helpful
I have installed docker engine v1.12.3 on Ubuntu 14.04 LTS and since after the following changes to enable Remote API, I'm not able to pull or run any of the docker images,
Added DOCKER_OPTS="-H tcp://127.0.0.1:2375" in /etc/default/docker.
/etc/init.d/docker start.
Following is the error received,
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?
Note: I have added login in user to the docker group
If you configure the docker daemon to listen to a TCP socket (as you do), you should use the -H command line option with the docker command to point it to that socket instead of the default Unix socket.
#mustaccio is correct. The docker command defaults to using a unix socket normally at /var/run/docker.sock. You can either make your options setup like:
DOCKER_OPTS="-H tcp://127.0.0.1:2375" -H unix:///var/run/docker.sock" and restart, or always use docker -H tcp://127.0.0.1:2375 whenever you interact with the host from the command line.
The only good scenario I've seen for removing the socket is pure user security. If your Docker host is TLS enabled, you can ensure only authorized people are accessing the host by signed certificates, not just people with access to the system.
I am trying to setup xdebug integration on my docker-based setup.
I am using Docker for Mac 1.12.0-rc2-beta17 with the "native" docker machine
I have a container, with xdebug installed, exposing port 9000 and mapping it to the port 9000:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6950c2a2b05d app "/usr/bin/supervisord" 9 minutes ago Up 9 minutes 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:2222->22/tcp app_1
When I'm trying to use PhpStorm to listen to the port 9000 for debug connections, I'm getting an error "Cannot listen: port 9000 is busy".
I must precise that I'm a newbie in networks..
It dependent how you want to connect via Xdebug
xdebug.remote_connect_back=1 said that PHP will wait until a HTTP request with GET parameter XDEBUG_SESSION_START=<IDE_key>. Then will PHP within the server try to connect back via port 9000 where your PHPStorm is listing. Classic don't call us, we will call you situation.
Now your situation with docker say simple, your container is responsible for port 9000. So PHP will get a loopback and PHPStorm isn't able to use port 9000 because its already used by your docker container.
So skip the assignment of port 9000 to docker, that will fix this situation.
You must bind 9000 port with --expose option.
This is the reference
if you are using docker compose sample docker-compose.yml file is here:
version: '2'
services:
your_app:
ports:
- "80:80"
expose:
- "9000"
image: "your-image:tag"
Firstly check your container logs to debug:
docker logs 6950c2a2b05d
or
docker logs app_1
Add -f flags for tail-like behavior:
docker logs -f app_1
Two things I discovered:
There is no need to expose the port 9000 on a container with xdebug (that seems rather counter-intuitive for me, as I do not exactly understand how my IDE connects to xdebug then).
I was able to use xdebug using the workaround described in https://forums.docker.com/t/ip-address-for-xdebug/10460/4.
How to run meteor on a different port, for example on port 80.
I tried to use meteor --port 80, but I get this error Error: listen EACCES
help me please.
Sounds like it might be access issue on your machine.
Check out this following answer, which might be related to your question. Quoting:
"As as a general rule processes running without root privileges cannot bind to ports below 1024.
So try a higher port, or run with elevated privileges via sudo."
So, you can see that sudo meteor run with your port number will work, but that you can address the root cause, which is fixing the node root privilege.
Node.js EACCES error when listening on most ports
You can't bind to ports < 1024 on Linux/Unix operating systems with a non-privileged account.
You could get around this by running meteor as root, but this is a really bad idea. In development mode, running as root will modify the permissions of the files under your application directory. In production, it's just a giant security hole. Never run a meteor app as root.
Listed below are the best practices depending on your environment.
Development
Run meteor on a high port number. The default is 3000 when you don't give a --port argument. Connect to it via the URL printed in the console - e.g. http://localhost:3000/.
Production
Here you have two choices:
Run meteor on a high port number and connect it to the outside world via a reverse proxy like nginx or HAProxy.
Start the webserver as root but step down the permissions once it's running using something like userdown. This is how mup works which, incidentally, is probably what you should be using to deploy your app.
run it with sudo
sudo meteor --port 80
The meteor run --port 8080 terminal command can be used.