Completely new to uWSGI (as of a few hours ago) and I've been tasked to disable logging. I found this is what I need to add to my ini file: disable-logging=True. In my ini file at /etc/uwsgi/vassals/data.ini, I have:
virtualenv = /opt/our-analytics/apis/env
chdir = /opt/our-analytics/apis/
wsgi-file = app.py
callable = wsgi_app
socket = 127.0.0.1:3031
logto = /var/log/uwsgi/%n.log
My question is, can I simply use nano to add this one-liner disable-logging=True to the bottom of the ini file? Would/should I remove the entire logto = /var/log/uwsgi/%n.log line at the same time?
Then run sudo systemctl restart emperor.uwsgi.service?
Thanks!
p.s. I already checked documentation that was shared via How to disable request logging in Django and uWSGI?, but:
This worked:
Add:
disable-logging=True
...to data.ini, then:
sudo systemctl restart emperor.uwsgi.service
cd to /var/log/uwsgi and:
rm data.log
then:
sudo systemctl restart emperor.uwsgi.service
If you are starting a small application, with flask for example, and not using a .ini file you can also include the flag --disable-logging in the command.
For example: uwsgi --http 127.0.0.1:8000 --wsgi-file flask_app.py --callable app --disable-logging
Related
This is my centos uwsgi service setting:
[Unit]
Description=uWSGI for uwsgi
After=syslog.target
[Service]
Restart=always
ExecStart=/usr/share/nginx/ENV/bin/uwsgi --ini /usr/share/nginx/ENV/config/uwsgi.ini
StandardError=syslog
KillSignal=SIGQUIT
Type=forking
PIDFile=/var/run/uwsgi.pid
[Install]
WantedBy=multi-user.target
And I want to convert to use supervisor to start/stop the uwsgi service
But still not find a solution
Please help me
This is my supervisor.conf :
[program:wiarea-positioning]
command = /usr/share/nginx/ENV/bin/uwsgi --ini /usr/share/nginx/ENV/config/uwsgi.ini
stdout_logfile=/var/log/uwsgi.log
stderr_logfile=/var/log/uwsgi.log
;stopasgroup = true
stopsignal=QUIT
This is my uwsgi.ini
[uwsgi]
chdir = /usr/share/nginx/ENV/mysite
env = DJANGO_SETTINGS_MODULE=mysite.settings
module = mysite.wsgi:application
# the virtualenv
home = /usr/share/nginx/ENV
master = true
thunder-lock=true
processes = 4
pidfile = /var/run/uwsgi.pid
socket = 127.0.0.1:8001
daemonize = /var/log/uwsgi.log
vacuum = true
I think your problem (at least one of them) is this uwsgi.ini line:
daemonize = /var/log/uwsgi.log
Remember that supervisor basically just runs your command= command from the command line, and waits for it to exit. If it exits, supervisor runs the command again.
The uwsgi daemonize option breaks this, because it causes the main uwsgi command to start a background process and immediately exit. Supervisor doesn't know about the background process, so it assumes the command failed and tries to restart it repeatedly. You can confirm this is what's happening by looking at the log files in the /var/log/supervisor/ folder.
So, if you want to run uwsgi with supervisor, you need to remove the daemonize option. After that, you can try just running the command from the command line to confirm that uwsgi starts and stays in the foreground.
This blog has more discussion of daemon processes and supervisor:
I am trying to run ruby on rails under passenger with apache2 under fedora 19 and I got this error in log:
[Tue Feb 25 09:37:52.367683 2014] [passenger:error] [pid 2779] ***
Passenger could not be initialized because of this error: Unable to
start the Phusion Passenger watchdog because it encountered the
following error during startup: Cannot change the directory
'/tmp/passenger.1.0.2779/generation-1/buffered_uploads' its UID to 48
and GID to 48: Operation not permitted (errno=1)
That directory (/tmp/passenger.1.0.2779) doesn't even exist. I think that problem is with selinux. I tried to solve it about 4 hours. Httpd is running under user apache and group apache, I tried:
cat /var/log/audit/audit.log | grep passenger | audit2allow -M
passenger semodule -i passenger.pp
but still nothing.
In your case, you should switch SELinux into Permissive mode at first, then try to capture the audit log from starting Apache to run your application.1
Once you got the home page of your application, you can build your custom policy with the logs.
Switch SELinux into Permissive mode and clean audit.log
]# setenforce 0
]# rm /var/log/audit/audit.log
]# service auditd restart
Restart Apache
]# service httpd restart
Try to open your application with a web browser
It might give more information about what is happenning when you application is running.
Make a custom policy module to allow these actions
]# mkdir work
]# cd work
]# grep httpd /var/log/audit/audit.log | audit2allow -M passenger
]# ls
passenger.pp passenger.te
Load postgrey policy module using the 'semodule' command into the current SELinux policy:
]# semodule -i passenger.pp
]# setenforce 1
Restart Apache
]# service httpd restart
References:
http://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01
I ran into a similar error, with a startup error about being unable to create a directory that did not exist. (logs, not tmp, but same sort of thing) I, too, battled with it for an hour and couldn't make sense of it. I created/deleted/chmod the directory many ways without success.
The fix for me was to change the parameters to passenger-start. Initially, my Docker container started passenger with:
exec bundle exec passenger start --auto --disable-security-update-check --min-instances 20 --max-pool-size 20 --max-request-queue-size 500
I removed all parameters, leaving just this:
exec bundle exec passenger start
At this point, passenger could create the log folder and file, and all was well. I could have restored the params at this point, but we decided they were not needed for the development environment so left them out moving ahead.
In hindsight, I have a hunch that I deleted the log directory while a file in it was still open, and the file system persisted that condition in some way. But that's just a hunch. Perhaps simply rebooting my Mac would have fixed it...
I have a uwsgiconfig.yaml like this
socket: /tmp/uwsgi/myapp/socket
chmod-socket: 666
But this doesn't work because there is no folder uwsgi or myapp in /tmp.
If I'm doing it like this, it works
socket: /tmp/uwsgi.myapp.socket
chmod-socket: 666
So why can not uWSGI just create the file by the full path? Or what should I do, what's the best practice?
This is a common UNIX pattern/best practice. Even mkdir does not do it without a proper flag.
If you want to create the directory tree you can use uWSGI hooks:
http://uwsgi-docs.readthedocs.org/en/latest/Hooks.html
if-not-dir = /tmp/uwsgi/
hook-asap = mkdir:/tmp/uwsgi/
end-if =
or
exec-asap = mkdir -p /tmp/uwsgi/myapp
I use a supervisor to run uWSGI application. Why uWSGI application does not always stop after stop supervisor?
supervisor config:
[program:test]
autostart = true
user=root
command=uwsgi --master --workers 5 --disable-logging --socket 127.0.0.1:8888
--module web --callable app
priority=1
redirect_stderr=true
stdout_logfile = /data/log
By default supervisor send SIGTERM on stop. SIGTERM in uWSGI means 'brutal reload'.
You have to change it to QUIT or INT:
stopsignal=QUIT
should be enough
Another approach (discouraged) is adding --die-on-term to uWSGI command line to change its default behaviour
project supervisor config file
add stopsignal=INT
project uwsgi config file
remove daemonize=xxx.log to disable daemon mode
If you use "processes = #" into your uwsgi configuration, you also must use "master = true". If not, supervisor only will kill one of workers.
Then:
/etc/supervisor/conf.d/app.conf
stopsignal = QUIT
/etc/uwsgi/app.ini
processes = 4
master = true
If you are running your UWSGI with master and workers you need to add in your /etc/supervisor/conf.d/app.conf file
stopasgroup=false
killasgroup=false
or else no matter what stopping uwsgi will spawn more master and so is workers.
I have an ubuntu server with a handful of custom environment variables set in /etc/environment as per the ubuntu community recommendation
When I use php from the command line I can use php's getenv() function to access this variables.
Also, if I run phpinfo() from the command line I see all of my variables in the ENVIRONMENT section.
However, when trying to access the same data inside processes being run by php5-fpm this data is not available. All I can see in the ENVIRONMENT section of phpinfo() is:
USER www-data
HOME /var/www
I know the command line uses this ini:
/etc/php5/cli/php.ini
And fpm uses:
/etc/php5/fpm/php.ini
I've not managed to find any differences between the two that would explain why the ENV variables are not coming through in both.
Also if run:
sudo su www-data
and then echo the environment variables I am expecting they are indeed available to the www-data user.
What do I need to do to get my environment variables into the php processes run by fpm?
It turns out that you have to explicitly set the ENV vars in the php-fpm.conf
Here's an example:
[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
[www]
user = www-data
group = www-data
listen = /var/run/php5-fpm.sock
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
chdir = /
env[MY_ENV_VAR_1] = 'value1'
env[MY_ENV_VAR_2] = 'value2'
1. Setting environment variables automatically in php-fpm.conf
clear_env = no
2. Setting environment variables manually in php-fpm.conf
env[MY_ENV_VAR_1] = 'value1'
env[MY_ENV_VAR_2] = 'value2'
! Both methods are described in php-fpm.conf:
Clear environment in FPM workers Prevents arbitrary environment
variables from reaching FPM worker processes by clearing the
environment in workers before env vars specified in this pool
configuration are added. Setting to "no" will make all environment
variables available to PHP code via getenv(), $_ENV and $_SERVER.
Default Value: yes
clear_env = no
Pass environment variables like LD_LIBRARY_PATH. All $VARIABLEs are
taken from the current environment. Default Value: clean env
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
I found solution in this github discussion .
The problem is when you run the php-fpm. The process not load the environment.
You can load it in the startup script.
My php-fpm is install by apt-get.
So modify the
/etc/init.d/php5-fpm
and add (beware the space between the dot and the slash)
. /etc/profile
and modify the /etc/profile to add
. /home/user/env.sh
In the env.sh. You can export the environment whatever you need.
Then modify
php-fpm.conf
add env[MY_ENV_VAR_1] = 'value1' under the [www] section.
Last. restart the php-fpm. You'll get the environment load by the fpm.
Adding on to the answers above, I was running php-fpm7 and nginx in an alpine:3.8 docker container. The problem that I faced was the env variables of USER myuser was not getting copied into the USER root
My entrypoint for docker was
sudo nginx # Runs nginx as daemon
sudo php-fpm7 -F -O # Runs php-fpm7 in foreground
The solution for this was
sudo -E nginx
sudo -E php-fpm7 -F -O
-E option of sudo copies all env variables of current user to the root
Of course, your php-fpm.d/www.conf file should have clear_env=no
And FYI, if you're using a daemon service like supervisord they have their own settings to copy the env. For example, supervisord has setting called copy_env=True