I am able to ssh into my droplet. Am also able to apt update and apt upgrade.
When I try to run sudo composer self-update or composer update, I am getting connection timeout error.
The "https://getcomposer.org/versions" file could not be downloaded: failed to open stream: Connection timed out
output of ufw status
To Action From
22 ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
25 ALLOW Anywhere
10000 ALLOW Anywhere
output of composer diagnose
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: FAIL
[Composer\Downloader\TransportException] The "http://packagist.org/packages.json" file could not be downloaded: failed to open stream: Connection timed out
Checking https connectivity to packagist: FAIL
[Composer\Downloader\TransportException] The "https://packagist.org/packages.json" file could not be downloaded: failed to open stream: Connection timed out
Checking github.com rate limit: OK
Checking disk free space: OK
Checking composer version:
[Composer\Downloader\TransportException]
The "https://getcomposer.org/version" file could not be downloaded: failed
to open stream: Connection timed out
output of composer --version
Composer version 1.0-dev (9e9c1917e1ed9f3f78b195a785aee3c6dc3cb883) 2015-11-23 10:31:23
output of curl IL http://packagist.org/packages.json
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 10 Dec 2017 08:40:20 GMT
Content-Type: application/json
Content-Length: 1302
Last-Modified: Sun, 10 Dec 2017 08:38:28 GMT
Connection: keep-alive
ETag: "5a2cf284-516"
Cache-Control: private, max-age=0, no-cache
Accept-Ranges: bytes
I tried to manually get a copy of latest composer but it also doesn't work
output of php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
PHP Warning: copy(https://getcomposer.org/installer): failed to open stream: Connection timed out in Command line code on line 1
What could be the reason? I was all working till about a week ago. I am able to visit (browse) the webpages hosted on my droplett. Am also able to apt update and apt upgrade.
You can run this command as root to make IPV4 more prior than IPV6:
sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
https://getcomposer.org/doc/articles/troubleshooting.md#operation-timed-out-ipv6-issues- could solve your problem. And if composer update is slow afterwards, try running it with a more recent PHP version. Running it with PHP 7 instead of PHP 5 will cause a big speedup
I also found a bug on executing composer command this last time about this timeout. Run "compose diag" then restart the command solved the problem if it is not related to ipv6
My Issue is caused by PHP 7.2, after switch back to PHP 7.1 'sphp 7.1', run the command 'composer update' again, and it works
Related
I have a spring boot application, and I run a performance test on it, using Gatling.
The issue is that after a few requests where everything works OK, the server returns connection refused and no other requests are working.
Gatling log looks like this:
---- Requests ------------------------------------------------------------------
> Global (OK=14 KO=1001 )
> POST /template (OK=13 KO=938 )
> PUT /feedback (OK=1 KO=63 )
---- Errors --------------------------------------------------------------------
> j.n.ConnectException: Connection refused: no further informati 577 (57,64%)
on
> j.i.IOException: Premature close 240 (23,98%)
> j.n.c.ClosedChannelException 184 (18,38%)
When I create a manual request using curl, returns:
$ curl https://localhost:8087
curl: (7) Failed to connect to localhost port 8087: Connection refused
If I connect to docker and do the request:
$ docker exec -it web /bin/bash
root#794f9e808f14:/# curl https://localhost:8443
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
SSL handshake failed, as expected, but this means that the server is up an running.
The port is mapped in docker:
$ docker port web
8443/tcp -> 0.0.0.0:8087
8443/tcp -> :::8087
After restart, all thing happen again.
I'm using docker on a WSL Ubuntu. Not sure if this matters too much. What can I do to make this connection more stable?
valet is not working after I updated php from 7.3 to 7.4. I already tried to reinstall valet, php, nginx and dnsmasq but it's still not working.
Now the ngix server is running but I can't acces to my projects. I get the error 502 Bad Gateway for every project url.
The services are running but brew services dont show the correct status.
dnsmasq unknown root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
gitlab-runner started user /Users/user/Library/LaunchAgents/homebrew.mxcl.gitlab-runner.plist
mysql#5.7 started user /Users/user/Library/LaunchAgents/homebrew.mxcl.mysql#5.7.plist
nginx unknown root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php error root /Library/LaunchDaemons/homebrew.mxcl.php.plist
php#7.4 unknown root /Library/LaunchDaemons/homebrew.mxcl.php#7.4.plist
redis started user /Users/user/Library/LaunchAgents/homebrew.mxcl.redis.plist
Nginx error log
2021/01/27 16:35:21 [crit] 35081#0: *1 connect() to unix:/Users/user/.config/valet/valet.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://unix:/Users/user/.config/valet/valet.sock:", host: "devtest.test", referrer: "http://devtest.test/"
I've managed to get mine working again.
I started by doing a full wipe down following the instructions that valet gives when you run valet uninstall which involved removing valet and all associated config, uninstalling php, nginx and dnsmasq via brew and cleaning up all remaining config. I then reinstalled everything, reconfigured my sites in valet and tried to load one up. Still I got the 502 Bad Gateway error.
I eventually tried running valet use php to make sure it was correctly bound to the right php version. Valet claimed that is was but I ran it again with the force flag just in case valet use php --force.
After that I was up and running again. Hopefully this might help you too.
What's strange is that my brew services list output lists dnsmasq, nginx and php as status unknown but they do all seem to be running correctly. I can't work out what's happening there but at least everything seems to be working again now.
I have a ubuntu server (on Azure) running proftpd, when I try to connect to that server using FileZilla sometimes it works, sometimes it doesn't (usually it doesn't work at first... and I need to keep trying several random times before it works... and once it does it works for good...), now this is the error I receive it FileZilla logs:
Status: Resolving address of ftp.myserver.com
Status: Connecting to xx.xx.xx.xx:21...
Status: Connection established, waiting for welcome message...
Status: Insecure server, it does not support FTP over TLS.
Command: USER my_user
Response: 331 Password required for my_user
Command: PASS *******
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server
Status: Waiting to retry...
Status: Resolving address of ftp.myserver.com
Status: Connecting to xx.xx.xx.xx:21...
Status: Connection established, waiting for welcome message...
Response: 220 ProFTPD 1.3.5a Server (Debian) [xx.xx.xx.xx]
Command: AUTH TLS
Response: 500 AUTH not understood
Command: AUTH SSL
Response: 500 AUTH not understood
Status: Insecure server, it does not support FTP over TLS.
Command: USER my_user
Response: 331 Password required for my_user
Command: PASS *******
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server
and this is what I see in proftpd logs:
2016-08-09 10:26:37,263 FTP proftpd[33961] 10.0.0.6 (yy.yy.yy.yy[yy.yy.yy.yy]): USER my_user: Login successful.
2016-08-09 10:26:37,264 FTP proftpd[33961] 10.0.0.6 (yy.yy.yy.yy[yy.yy.yy.yy]): FTP session closed.
2016-08-09 10:26:37,468 FTP proftpd[33970] 10.0.0.6 (yy.yy.yy.yy[yy.yy.yy.yy]): FTP session opened.
I don't know why the server closes and reopens the connection after the login but I am no FTP expert...
Any thoughts on how to fix this?
Edit:
This is the content of proftpd.conf file
There are multiple possible causes for a delay at login time with ProFTPD. The most common causes are the mod_delay module (see its FAQ), or IdentLookups or UseReverseDNS.
However, since your delay happens after the PASS command has been sent, that rules out the IdentLookups or UseReverseDNS directives, as those pertain to the initial connection establishment, before any commands are sent.
Per discussion with the reporter, any latency added by mod_delay was ruled out. That leaves PAM, which, depending on the configuration (e.g. in /etc/pam.d/ftp) and the modules used, can add its own latency (over which ProFTPD has little control). To disable ProFTPD's use of PAM, you would use the following in the config:
<IfModule mod_auth_pam.c>
AuthPAM off
</IfModule>
The reporter mentioned that disabling the use of PAM did indeed remove the delay -- thus pointing out that one of the PAM modules was the root cause.
Hope this helps!
I've setup my gitlab installation from source, secured it with letsencrypt and deployed it under https://gitlab.mydomain.com. I can access the website and create repositories, etc. but I can't find a way to register a gitlab ci runner for the installation.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
https://gitlab.mydomain.com/ci
Please enter the gitlab-ci token for this runner:
xxxxxxxx-xxxxxxxx
Please enter the gitlab-ci description for this runner:
[server]: test
Please enter the gitlab-ci tags for this runner (comma separated):
test
ERROR: Registering runner... failed runner=xxxxxxx
status=couldn't execute POST against https://gitlab.mydomain.com/ci/api/v1/runners/register.json:
Post https://gitlab.mydomain.com/ci/api/v1/runners/register.json:
read tcp [ipv6address]:33518->[ipv6address]:443: read: connection reset by peer
PANIC: Failed to register this runner. Perhaps you are having network problems
My gitlab system is working fine and I really ran out of explanations why there would be a connection reset by peer. When I try to curl the address from the error message directly, it returns a correct response.
curl -v https://gitlab.mydomain.com/ci/api/v1/runners/register.json
* Trying ipv6address...
* Connected to gitlab.mydomain.com (ipv6address) port 443 (#0)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* found 700 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: mydomain.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=mydomain.com
* start date: Wed, 18 May 2016 14:35:00 GMT
* expire date: Tue, 16 Aug 2016 14:35:00 GMT
* issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
* compression: NULL
* ALPN, server did not agree to a protocol
> GET /ci/api/v1/runners/register.json HTTP/1.1
> Host: gitlab.mydomain.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
< Server: nginx
< Date: Sun, 29 May 2016 09:14:09 GMT
< Content-Type: application/json
< Content-Length: 2
< Connection: keep-alive
< Allow: OPTIONS, POST
< Cache-Control: no-cache
< Status: 405 Method Not Allowed
If the runner and gitlab are running on the same host you can get around this problem by entering a the first question the following instead what is given in the docs:
http://gitlab:port
where gitlab is the container name and port the left port number of the container. If you are using gitlab internal ssl certs you specify https instead of http. This always solves this problem when I get it.
For those that are using docker:
The issue its about docker network.
If you try
"$docker container inspect $id"
You are going to see the IPAddress of gitlab container.
Point to that ip adress on first question to works fine.
Problem went away after updating gitlab to 8.8.3 and gitlab-multi-ci-runner to the most recent version.
I also started my gitlab nginx configuration files from scratch.
In the end, I can't tell which change exactly solved the problem.
I had so far many errors and issue starting with Error 404, 403 and endings with problem with post request.
For me, problem seems to be incompatibility between GitLab and ci-runner.
Solution, same on post issue, was install older version of ci-runner:
sudo apt install gitlab-ci-multi-runner=1.11.1
I've solved it by installing gitlab-ci-multi-runner=1.11.1.
I ported vsftpd on my ARM based board running under linux 3.0.8 kernel.
When I try to establish a ftp connection to the board using Filezilla (3.7.3), I get the following error:
Status: Connecting to XXX.XXX.XXX.XXX:21
Status: Connection established, waiting for welcome message...
Response: 220 (vsFTPd 3.0.2)
Command: USER anonymous
Response: 331 Please specify the password.
Command: PASS **************
Response: 230 Login successful.
Command: OPTS UTF8 ON
Response: 200 Always in UTF8 mode.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/"
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: PASV
Response: 500 OOPS: socket
Error: Failed to retrieve directory listing
Error: Connection closed by server
Command: PASV
Response: 500 OOPS: socket
Error: Failed to retrieve directory listing
Error: Connection closed by server
The configuration used for my server is as follow:
listen=YES
max_clients=2
max_per_ip=4
# Access rights
anonymous_enable=YES
local_enable=NO
write_enable=NO
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
# Security
anon_world_readable_only=YES
connect_from_port_20=YES
hide_ids=YES
pasv_enable=yes
pasv_min_port=0
pasv_max_port=0
# Features
xferlog_enable=YES
ls_recurse_enable=NO
ascii_download_enable=NO
async_abor_enable=YES
# Performance
one_process_model=YES
idle_session_timeout=120
data_connection_timeout=300
accept_timeout=60
connect_timeout=60
anon_max_rate=50000
pam_service_name=vsftpd
port_enable=YES
log_ftp_protocol=YES
There is no firewall installed in my board.
When I force the ftp connection mode to ACTIVE mode, I can connect to the server, retrieve data, upload files ...
I tried with several ftp server, but I always face the same issue.
Any idea what could be the issue?
Could be that there is some kernel module missing?