I'm facing with this error from few days, maybe weeks. I've tried and tried and tried all kind of solutions over the internet but with no success, so:
I have a dedicated server with Plesk 12 and Ubuntu 14.04 LTS.
This error appear daily, 1-2 times per day and I have to restart whole server and then all websites are working properly until next time this error appear again.
First time it appeared when I have added two more domains to be hosted. I suspected high server loading but no, rams never gets almost completely and cpu load is max 20%.
PS: Error appear only on websites, so I can access Plesk Panel and reboot server.
NGINX error log (/var/log/nginx/error.log):
[error] 1406#0: *119083 connect() failed (111: Connection refused) while connecting to upstream, client: IP, server: , request: "GET http://www.example.com/ HTTP/1.1", upstream: "http://SERVER_IP:7080/", host: "www.example.com"
It is first time when I'm using Plesk and I don't really know how to do or check... .
PS: Can this be caused by a cron job service?
Cron log which is worrying me:
254 postfix/master[1664]: warning: master_wakeup_timer_event: service pickup(public/pickup): Connection refused
"(111: Connection refused) while connecting to upstream"
this error means that something goes wrong with Apache or PHP-FPM(if you have using it), check apache logs of site where it happens: /var/www/vhosts/examples.com/logs/error_log
Related
Linux installation of Phusion Passenger(R) 6.0.14 on nginx/1.14.1. I'm not able to load a site (on a simplified nginx.conf with the conf.d/passenger.conf and conf.d/site1.conf includes. That error:
2022/08/03 19:24:34 [alert] 55601#0: *3 Error opening '/home/user3/sites/Passengerfile.json' for reading: Permission denied (errno=13);
This error means that the Nginx worker process (PID 55601, running as UID 992) does not have permission to access this file.
Please read this page to learn how to fix this problem: https://www.phusionpassenger.com/library/admin/nginx/troubleshooting/?a=upon-accessing-the-web-app-nginx-reports-a-permission-denied-error;
Extra info, client: 192.168.1.4, server: domain1.com, request: "GET / HTTP/1.1", host: "server_f.local"
I don't even know what to ask, other than how can I get this to work? That file doesn't exist. I've restarted nginx many times, and this is the only feedback that I get. I've checked over that page, which tells me to look at the error log it's reported in already. The host and server are correct, and I am on my LAN.
I've been running nextcloud on arch linux for months and have never gotten large files to work properly. Gotten dozens of suggestions that haven't worked. When I try and upload a large file it says something like "Error when assembling chunks. Status code 504." It will still upload fine despite the warning. When you try and download the large file it will stop every 1GB. Running uwsgi as the application server and nginx as web server. It stops at exactly 1GB so I'm sure it's not a timing issue and more of a max upload file size issue.
Journal when trying to upload large file: Apr 05 20:06:58 thinkArch nginx[287526]: 2022/04/05 20:06:58 [error] 287526#287526: *63144 upstream prematurely closed connection while reading upstream, client: 192.168.50.1, server: cloud.atavismxi.com, request: "GET /remote.php/webdav/AtavismXI/AtavismXI-Installer-1.61.zip HTTP/1.1", upstream: "uwsgi://unix:/run/uwsgi/nextcloud.sock:", host: "cloud.atavismxi.com"
Below are my conf files. Some of the suggestions other people made are still in them. Some of the suggestions are gone. But I've tried a lot of different nginx settings.
php.ini: https://pastebin.com/gzdxGBqD
post_max_size = 5G
nextcloud.ini (for uwsgi) https://pastebin.com/18e1Fwip
php-set = upload_max_filesize=10G
nginx.conf: https://pastebin.com/X8GWikHj
client_max_body_size 0;
I have NGINX working as a cache engine and can confirm that pages are being cached as well as being served from the cache. But the error logs are getting filled with this error:
2018/01/19 15:47:19 [crit] 107040#107040: *26 chmod()
"/etc/nginx/cache/nginx3/c0/1d/61/ddd044c02503927401358a6d72611dc0.0000000007"
failed (1: Operation not permitted) while reading upstream, client:
xx.xx.xx.xx, server: *.---.com, request: "GET /support/applications/
HTTP/1.1", upstream: "http://xx.xx.xx.xx:80/support/applications/",
host: "---.com"
I'm not really sure what the source of this error could be since NGINX is working. Are these errors that can be safely ignored?
It looks like you are using nginx proxy caching, but nginx does not have the ability to manipulate files in it's cache directory. You will need to get the ownership/permissions correct on the cache directory.
Not explained in the original question is that the mounted storage is an Azure file share. So in the FSTAB I had to include the gid= and uid= for the desired owner. This then removed the need for chown and chmod also became unnecessary. This removed the chmod() error but introduced another.
Then I was getting errors on rename() without permission to perform this. At this point I scrapped what I was doing, moved to a different type of Azure storage (specifically a Disk attached to the VM) and all these problems went away.
So I'm offering this as an answer but realistically, the problem was not solved.
We noticed the same problem. Following the guide from Microsoft # https://learn.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv#create-a-storage-class seems to have fixed it.
In our case the nginx process was using a different user for the worker threads, so we needed to find that user's uid and gid and use that in the StorageClass definition.
i am new to nginx, yesterday i installed lemp on centos and hosted a website on. today i get this in error message. please tell me if this is a security bug of nginx? Thank you!
cat /var/log/nginx/error.log
2017/07/01 03:52:18 [error] 6073#0: *23151 open() "/usr/share/nginx/html/testproxy.php" failed (2: No such file or directory), client: 91.196.50.33, server: _, request: "GET http://testp3.pospr.waw.pl/testproxy.php HTTP/1.1", host: "testp3.pospr.waw.pl"
It's not an nginx bug: If you're currently running a site that's live and accessible on the internet, bot scripts will try to find common vulnerabilities by hitting your server with various automated requests of common URLs, paths and patterns (e.g. admin.php, /wp-login.php for WordPress blogs...). Just make sure you set up proper security for your server and you'll be fine.
I'm having a problem with Memcached pools. I will try to add all the context of the error to see if you guys can help me with this.
Context:
PHP 5.5.17 (cgi-fcgi) (built: Sep 24 2014 20:38:04)
php-pecl-memcache-3.0.8-2.fc17.remi.5.5.x86_64
nginx version:
nginx/1.0.15
My problem:
I am creating a connection with memcached and saving a several keys, just in one server first, something like this:
$_memcache = new Memcache;
$_memcache->addServer("127.0.0.1", "11211", true, 50, 3600, 45);
So, let suppose that I add several keys, in that server and I can get those without problem, I actually can, when I see my site and my code is calling to get the keys, it's getting it.
Now the problem, let say with those keys already saved and working without problem, I added another memcached server to the pool, this way:
$_memcache = new Memcache;
$_memcache->addServer("10.0.0.2", "11211", true, 50, 3600, 45);
$_memcache->addServer("10.0.0.3", "11211", true, 50, 3600, 45);
But before I refreshed the site to run my code and get the keys that I have storage in the first server I stopped the memcached in that server number 1 (10.0.0.2), after that I refreshed my site and then I received a 502 error (Bad Gateway)
The error that I am seeing in the log of NGINX is:
[error] 9364#0: *329504 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XX.XX.XXX.XXX, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php-fastcgi/sock:", host: "www.myhost.com"
So, why I am getting that error. The only theory that I have is that for some reason because the connections is persistent is not closing properly when I stop the memcached server, but that only happens when I have a pool of X > 1 servers. If I use just that one and stopped I won't see the error.
There is any way that PHP 5.5 has a bug with the fastcgi socket that I don't know.
NOTE: This problem that I am having wasn't happening on previous PHP version 5.3, after changing the version is this is happening.
NOTE: When I don't use persistent connection seems to work, but this site has a huge traffic and it won't handle the amount of connections open, I tested this in dev environment.
Any help or any suggestions are more than welcome.
Thanks in advance!