nginx : access.log and error.log file empty - nginx

I have just installed nginx on Ubuntu 14.04 using the command
sudo apt-get install nginx
Now, when I open my browser and type in the address localhost then I am correctly shown the "Welcome to nginx" page. Also, I checked the config file located in /etc/nginx/nginx.conf and found the following log settings:
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
However, when I check these two files, both are empty. I have opened the localhost page multiple times but still the log files are empty. What might be wrong with my setup ?

I had the same issue after reinstalling nginx to newer version. Seems like log files ownership changed and new nginx couldn't save anything there.
Removing log files and reloading nginx worked for me:
$ sudo rm -f /var/log/nginx/*
$ sudo nginx -s reload

It looks like by default they are set to go to stdout and stderr.
lrwxrwxrwx 1 root root 11 Apr 27 2016 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Apr 27 2016 error.log -> /dev/stderr
So you can remove the symlinks and should be fine.
rm -f /var/log/nginx/*

For all of those whose, like me, came here to figure out why the logs file are empty, and did not realise that you might actually be inside a docker container like one of the comments on another answer suggests, just open a new shell and tail the logs with
docker logs {your-container-id-here} -f

By default Nginx image output the logs access/error to stdout/stderr.
lrwxrwxrwx 1 root root 11 Apr 27 2016 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Apr 27 2016 error.log -> /dev/stderr
We can also check the same by visit this Nginx Dockerfile, look for the comment # forward request and error logs to docker log collector
Now Use the below configuration in order to view the files.
I have changed file name
*error.log = error.logs
access.log = access.logs*
error_log /var/log/nginx/error.logs notice;
access_log /var/log/nginx/access.logs;

Your answer is here
Step1: Open the rsyslog config file
#vi /etc/rsyslog.conf
Step2: Add the following line before the line $IncludeConfig /etc/rsyslog.d/*.conf
$ModLoad imfile
Step3: Create a new file for nginx rsyslog configuration
#vi /etc/rsyslog.d/nginx.conf
Step4: Update the following lines.
# error log
$InputFileName /var/log/nginx/error.log
$InputFileTag nginx:
$InputFileStateFile stat-nginx-error
$InputFileSeverity error
$InputFileFacility local6
$InputFilePollInterval 1
$InputRunFileMonitor
# access log
$InputFileName /var/log/nginx/access.log
$InputFileTag nginx:
$InputFileStateFile stat-nginx-access
$InputFileSeverity notice
$InputFileFacility local6
$InputFilePollInterval 1
$InputRunFileMonitor
Step5: Restart rsyslog service
#service rsyslog restart

Related

Nginx: Can't open error.log, cannot load certificate [how to fix permissions?]

So I have a homeserver running nginx which is serving a Nextcloud instance. The Nextcloud instance is working beautifully, but I'm getting nginx self-reported errors like such when executing
nginx -t
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2020/02/27 15:50:55 [warn] 6985#6985: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2020/02/27 15:50:55 [emerg] 6985#6985: cannot load certificate "/etc/letsencrypt/live/myserver.com/fullchain.pem": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/myserver.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)
nginx: configuration file /etc/nginx/nginx.conf test failed
not quite sure what to do about that - my google-fu is failing me for now. It seems it might have something to do with getting permissions set right, but ls -l /etc/letsencrypt/live/myserver.com outputs
lrwxrwxrwx 1 root ssl-cert 36 Jan 21 08:38 cert.pem -> ../../archive/myserver.com/cert1.pem
lrwxrwxrwx 1 root ssl-cert 37 Jan 21 08:38 chain.pem -> ../../archive/myserver.com/chain1.pem
lrwxrwxrwx 1 root ssl-cert 41 Jan 21 08:38 fullchain.pem -> ../../archive/myserver.com/fullchain1.pem
lrwxrwxrwx 1 root ssl-cert 39 Jan 21 08:38 privkey.pem -> ../../archive/myserver.com/privkey1.pem
-rw-r--r-- 1 root ssl-cert 692 Jan 21 08:38 README
ls -l -R /var/log/nginx doesn't do anything, but executing it as sudo yields:
-rwxrw-rw- 1 www-data www-data 6553 Feb 27 15:19 access.log
for every entry. Does that seem alright?
EDIT: #RichardSmith is the man, his comment below pointing out to run nginx -t as sudo did the trick. I feel slightly stupid now, so thanks man ;). sudo nginx -T now also works, allowing me to further troubleshoot another problem.
#RichardSmith's comment suggested running nginx -t as sudo, which did the trick.
sudo nginx -T now also works, allowing me to further troubleshoot another problem.

Nginx can't serve static content and return 403(Forbidden) error page

I am new to nginx and trying to serve static contents with nginx and getting 403 error.I have server config like this:
server {
listen 8000;
server_name localhost;
root /Users/ismayilmalik/Documents/github/nginx-express;
location / {
index index.html;
}
I have executed commands below:
chmod -R 755 /nginx-express
chmod -R 644 /nginx-express/*.*
And the folder has drwxr-xr-x rigt.What's wrong here?
Please go to your nginx error logs to get details.
Run this command to show last errors:
tail -20 /var/log/nginx/error.log
It's good to go through error logs located /var/log/nginx/***.error. I had problems similar to this once. The solution was the user nginx was running as.
If nginx is running as www then www will not have access to ismayilmalik folders unless you also grant access to /Users/ismayilmalik home folder, but that is not secure. The best solution would be to allow nginx to run as ismayilmalik if you want to access your home folder through nginx.
I solved it finally.Actually nginx had all permission to serve static content from:
/Users/ismayilmalik/Documents/github/nginx-express;
The reason was when started nginx could not create error.log file in it'sroot directory. After manually creating the file it worked fine. I am using macOs and to find logs folder executed the command below to find all enironment variables for nginx:
nginx -V
BTW before this I had changed nginx user to from nobody to admin in main config file like below.
user [username] [usergroup]
By default nginx master process runs under root and child process under nobody.

403 forbidden error with Nginx despite permissions being set

My actual problem is that Nginx is not able to render pages (403 forbidden) despite the permissions being set to 755 for nginx:nginx.
I am using the following command...
[root#wfe1 user1]# strace -p 26934 -e trace=file
Process 26934 attached
stat("/home/user1/site3/index.html", {st_mode=S_IFREG|0755, st_size=6, ...}) = 0
open("/home/user1/site3/index.html", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied)
The output as you can see is Permission Denied. I would like to know which user account was used to access the file? How can I dig in further?
[root#wfe1 user1]# ls -al site3
total 8
drwxr-xr-x. 2 nginx nginx 23 Mar 6 06:12 .
drwx------. 5 user1 user1 4096 Mar 6 06:12 ..
-rwxr-xr-x. 1 nginx nginx 6 Mar 6 06:12 index.html
Take a look in the nginx access logs to see where things are failing
Use ps aux | grep nginx to see which user nginx is running as.
Make sure you have the correct "allow all" permissions set in your nginx config / location stanza.

Nginx error: (13: Permission denied) while connecting to upstream

I am getting this error in my nginx-error.log file:
2014/02/17 03:42:20 [crit] 5455#0: *1 connect() to unix:/tmp/uwsgi.sock failed (13: Permission denied) while connecting to upstream, client: xx.xx.x.xxx, server: localhost, request: "GET /users HTTP/1.1", upstream: "uwsgi://unix:/tmp/uwsgi.sock:", host: "EC2.amazonaws.com"
The browser also shows a 502 Bad Gateway Error. The output of a curl is the same, Bad Gateway html
I've tried to fix it by changing permissions for /tmp/uwsgi.sock to 777. That didn't work. I also added myself to the www-data group (a couple questions that looked similar suggested that). Also, no dice.
Here is my nginx.conf file:
nginx.conf
worker_processes 1;
worker_rlimit_nofile 8192;
events {
worker_connections 3000;
}
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
I am running a Flask application with Nginsx and Uwsgi, just to be thorough in my explanation. If anyone has any ideas, I would really appreciate them.
EDIT
I have been asked to provide my uwsgi config file. So, I never personally wrote my nginx or my uwsgi file. I followed the guide here which sets everything up using ansible-playbook. The nginx.conf file was generated automatically, but there was nothing in /etc/uwsgi except a README file in both apps-enabled and apps-available folders. Do I need to create my own config file for uwsgi? I was under the impression that ansible took care of all of those things.
I believe that ansible-playbook figured out my uwsgi configuration since when I run this command
uwsgi -s /tmp/uwsgi.sock -w my_app:app
it starts up and outputs this:
*** Starting uWSGI 2.0.1 (64bit) on [Mon Feb 17 20:03:08 2014] ***
compiled with version: 4.7.3 on 10 February 2014 18:26:16
os: Linux-3.11.0-15-generic #25-Ubuntu SMP Thu Jan 30 17:22:01 UTC 2014
nodename: ip-10-9-xxx-xxx
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /home/username/Project
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 4548
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/uwsgi.sock fd 3
Python version: 2.7.5+ (default, Sep 19 2013, 13:52:09) [GCC 4.8.1]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1f60260
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72760 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x1f60260 pid: 26790 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 26790, cores: 1)
The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts.
The correct way to solve the problem is to make uwsgi change the ownership and/or permission of /tmp/uwsgi.sock such that nginx can write to this socket. Therefore, there are three possible solutions.
Run uwsgi as the www-data user so that this user owns the socket file created by it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --uid www-data --gid www-data
Change the ownership of the socket file so that www-data owns it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chown-socket=www-data:www-data
Change the permissions of the socket file, so that www-data can write to it.
uwsgi -s /tmp/uwsgi.sock -w my_app:app --chmod-socket=666
I prefer the first approach because it does not leave uwsgi running as root.
The first two commands need to be run as root user. The third command does not need to be run as root user.
The first command leaves uwsgi running as www-data user. The second and third commands leave uwsgi running as the actual user that ran the command.
The first and second command allow only www-data user to write to the socket. The third command allows any user to write to the socket.
I prefer the first approach because it does not leave uwsgi running as root user and it does not make the socket file world-writeable .
While the accepted solution is true there might also SELinux be blocking the access. If you did set the permissions correctly and still get permission denied messages try:
sudo setenforce Permissive
If it works then SELinux was at fault - or rather was working as expected! To add the permissions needed to nginx do:
# to see what permissions are needed.
sudo grep nginx /var/log/audit/audit.log | audit2allow
# to create a nginx.pp policy file
sudo grep nginx /var/log/audit/audit.log | audit2allow -M nginx
# to apply the new policy
sudo semodule -i nginx.pp
After that reset the SELinux Policy to Enforcing with:
sudo setenforce Enforcing
Anyone who lands here from the Googles and is trying to run Flask on AWS using the default Ubuntu image after installing nginx and still can't figure out what the problem is:
Nginx runs as user "www-data" by default, but the most common Flask WSGI tutorial from Digital Ocean has you use the logged in user for the systemd service file. Change the user that nginx is running as from "www-data" (which is the default) to "ubuntu" in /etc/nginx/nginx.conf if your Flask/wsgi user is "ubuntu" and everything will start working. You can do this with one line in a script:
sudo sed -i 's/user www-data;/user ubuntu;/' /etc/nginx/nginx.conf
Trying to make Flask and uwsgi run as www-data did not work off the bat, but making nginx run as ubuntu worked just fine since all I'm running with this instance is Flask anyhow.
You have to set these permissions (chmod/chown) in uWSGI configuration.
It is the chmod-socket and the chown-socket.
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chmod-socket
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#chown-socket
Nginx connect to .sock failed (13:Permission denied) - 502 bad gateway
change the name of the user on the first line in /etc/nginx/nginx.conf file.
the default user is www-data and change it to root or your username
I know it's too late, but it might helps to other. I'll suggest to follow Running flask with virtualenv, uwsgi, and nginx very simple and sweet documentation.
Must activate your environment if you run your project in virtualenv.
here is the yolo.py
from config import application
if __name__ == "__main__":
application.run(host='127.0.0.1')
And create uwsgi.sock file in /tmp/ directory and leave it blank.
As #susanpal answer said "The permission issue occurs because uwsgi resets the ownership and permissions of /tmp/uwsgi.sock to 755 and the user running uwsgi every time uwsgi starts." it is correct.
So you have to give permission to sock file whenever uwsgi starts.
so now follow the below command
uwsgi -s /tmp/uwsgi.sock -w yolo:application -H /var/www/yolo/env --chmod-socket=666
A little different command from #susanpal.
And for persist connection, simply add "&" end of command
uwsgi -s /tmp/uwsgi.sock -w yolo:app -H /var/www/yolo/env --chmod-socket=666 &
In my case changing some php permission do the trick
sudo chown user:group -R /run/php
I hope this helps someone.
You should post both nginx and uwsgi configuration file for your application (the ones in /etc/nginx/sites-enabled/ and /etc/uwsgi/ - or wherever you put them).
Typically check that you have a line similar to the following one in your nginx app configuration:
uwsgi_pass unix:///tmp/uwsgi.sock;
and the same socket name in your uwsgi config file:
socket=/tmp/uwsgi.sock

Nginx trying to log to /var/logs instead of /var/log?

I noticed when I test my nginx config using nginx -t, it gives me a warning:
nginx: [alert] could not open error log file: open() "/var/logs/nginx/error.log" failed (2: No such file or directory)
Which makes sense, since the log path for nginx is actually set up to be /var/log/nginx/ not /var/logs/nginx.
I scanned the entire nginx config directory and there is nothing there referencing /var/logs. I'm at a loss as to where this log location could be written?
Run this command in a terminal (note: capital V):
nginx -V
Do you find /var/logs there? Your nginx might be compiled with that default file location.
[EDIT]
I guess that some of your server blocks don't have the "error_log" directive. So nginx tries the default one for them. Note that by default the error_log is always on.
To fix this issue, you can add this line on the main block (the top level) such that all child blocks can inherit the setting:
error_log /var/log/nginx/error.log;
You can create these missed files:
cd /var/log/nginx/
sudo touch error.log
sudo touch access.log
sudo chmod 750 *.log
Then trigger nginx service:
sudo systemctl daemon-relod
sudo service nginx restart
[NOTE]:
You can also disable nginx logging:
disable nginx logging (1)
disable nginx logging (2)
You have a bad compiled default. Anything nginx notices before loading the config goes to the path for the error log defined at compile time. Recompile nginx with sane path or symlink log to logs if you can't.

Resources