A deployment fails with the following message:
Phusion Passenger(R) doesn't seem to be running. If you are sure that it
is running, then the causes of this problem could be one of:
[...]
• You customized Nginx's passenger_instance_registry_dir option
• The instance directory has been removed by an operating system background service. Please set a different instance registry directory Phusion Passenger(R) Standalone's --instance-registry-dir command line argument.
[...]
DEBUG [25d4f5b4] *** Cleaning stale instance directory /tmp/passenger.7OMaC6P
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.7OMaC6P/.
*** Cleaning stale instance directory /tmp/passenger.0bmUABH
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.0bmUABH/.
*** Cleaning stale instance directory /tmp/passenger.n1oLEes
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.n1oLEes/.
*** Cleaning stale instance directory /tmp/passenger.RXBYda3
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.RXBYda3/.
*** Cleaning stale instance directory /tmp/passenger.TrAwTXq
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.TrAwTXq/.
*** Cleaning stale instance directory /tmp/passenger.vZaExdN
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.vZaExdN/.
*** Cleaning stale instance directory /tmp/passenger.dqTKpv1
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.dqTKpv1/.
*** Cleaning stale instance directory /tmp/passenger.hh2TxgL
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.hh2TxgL/.
*** Cleaning stale instance directory /tmp/passenger.rjowwmi
Warning: Operation not permitted # rb_file_chown - /tmp/passenger.rjowwmi/.
passenger-status runs. However two pids are shown
App root: /home/deploy/margin/current
Requests in queue: 0
* PID: 110639 Sessions: 0 Processed: 46 Uptime: 12h 29m 50s
CPU: 1% Memory : 409M Last used: 2m 50s
* PID: 141836 Sessions: 0 Processed: 0 Uptime: 2m 46s
CPU: 0% Memory : 17M Last used: 2m 46s ago
Installation occured via these commands:
sudo apt-get install -y nginx-extras libnginx-mod-http-passenger
if [ ! -f /etc/nginx/modules-enabled/50-mod-http-passenger.conf ]; then sudo ln -s /usr/share/nginx/modules-available/mod-http-passenger.load /etc/nginx/modules-enabled/50-mod-http-passenger.conf ; fi
sudo ls /etc/nginx/conf.d/mod-http-passenger.conf
the conf file has
passenger_root /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini;
passenger_ruby /home/deploy/.rbenv/shims/ruby;
While there is documentation on this matter, it does not cover a gap in understanding - and thus does not mitigate risk. Namely:
• rather, is not a question of all these stale instances which is gumming up the works? How to get rid of properly?
• uncertainty as to whether passenger standalone or nginx variant is running - how to verify?
• there is no recollection of ever touching passenger_instance_registry_dir
• if a system background service has been run to change the instance directory, how can one verify?
• what is good practice for eventually setting and instance directory?
Related
I am trying to set up repmgr version 5 on Debian with PostgtrSql 11.
Seems like the documentation is more oriented towards centos/RHEL.
When I am trying to setup the witnes node to start the repmgr daemon, I get an error without any idea where to look for for seeing what is the cause of the error.
This is my repmgr.conf file:
node_id=3
node_name='PG-Node-Witness'
conninfo='host=10.97.7.140 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/11/main'
failover='automatic'
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
priority=60
monitor_interval_secs=2
connection_check_type='ping'
reconnect_attempts=6
reconnect_interval=8
primary_visibility_consensus=true
standby_disconnect_on_failover=true
repmgrd_service_start_command='sudo /etc/init.d/repmgrd start' #??????
repmgrd_service_stop_command='sudo //etc/init.d/repmgrd stop'#??????
service_start_command='sudo /usr/bin/systemctl start postgresql#11-main.service'
service_stop_command='sudo /usr/bin/systemctl stop postgresql#11-main.service'
service_restart_command='sudo /usr/bin/systemctl restart postgresql#11-main.service'
service_reload_command='sudo /usr/bin/systemctl relaod postgresql#11-main.service'
monitoring_history=yes
log_status_interval=60
register is OK:
repmgr -f /etc/repmgr.conf witness register -h 10.97.7.97
INFO: connecting to witness node "PG-Node-Witness" (ID: 3)
INFO: connecting to primary node
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
INFO: witness registration complete
NOTICE: witness node "PG-Node-Witness" (ID: 3) successfully registered
repmgr daemon dry-run OK too:
$repmgr -f /etc/repmgr.conf daemon start --dry-run
INFO: prerequisites for starting repmgrd met
DETAIL: following command would be executed:
sudo /usr/bin/systemctl start postg...#11-main.service
I setup /etc/default/repmgrd with:
REPMGRD_ENABLED=yes
and
REPMGRD_CONF="/etc/repmgr.conf"
But still get error when trying to run the daemon start:
$ repmgr -f /etc/repmgr.conf daemon start
I get:
NOTICE: executing: "sudo /etc/init.d/repmgrd start"
ERROR: repmgrd does not appear to have started after 15 seconds
HINT: use "repmgr service status" to confirm that repmgrd was successfully started
It is recommended to run repmgrd as a systemd service,
According to the docs (for debian) you may first need to configure /etc/default/repmgrd,
My configuration looks like this:
# default settings for repmgrd. This file is source by /bin/sh from
# /etc/init.d/repmgrd
# disable repmgrd by default so it won't get started upon installation
# valid values: yes/no
REPMGRD_ENABLED=yes
# configuration file (required)
REPMGRD_CONF="/etc/repmgr/12/repmgr.conf"
# additional options
REPMGRD_OPTS="--daemonize=false"
# user to run repmgrd as
REPMGRD_USER=postgres
# repmgrd binary
REPMGRD_BIN=/bin/repmgrd
# pid file
REPMGRD_PIDFILE=/var/run/repmgrd.pid
Secondly, I would revisit sudoers (visudo) in order to check whether the non-root user can execute sudo /etc/init.d/repmgrd start.
Further, the user who runs repmgr commands should be able to write logs depending on your configuration.
Apparently the correct command to start the repmgr daemon is:
repmgrd -f /etc/prepmgr.conf
brew
brew install not work. this is the log.
% brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.4.13.mojave.bottle.tar.gz
Already downloaded: /Users/shingo/Library/Caches/Homebrew/downloads/d56104142081a8230646ac3f245adf2414e515cd5f2aeeb0637614e9966e882c--mariadb-10.4.13.mojave.bottle.tar.gz
==> Pouring mariadb-10.4.13.mojave.bottle.tar.gz
==> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
Last 15 lines from /Users/shingo/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall mariadb`
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
MySQL is configured to only allow connections from localhost by default
To start mariadb:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.4.13: 744 files, 169.9MB
I have tried to execute mysql_install_db
I have tried to execute mysql_install_db without brew. this is the log.
The brew displays only the last 15 lines, so I can't help it.
% /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
chown: /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool: Operation not permitted
Couldn't set an owner to '/usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool'.
It must be root, the PAM authentication plugin doesn't work otherwise..
Installing MariaDB/MySQL system tables in '/usr/local/var/mysql' ...
2020-05-29 22:13:03 0 [Note] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld (mysqld 10.4.13-MariaDB) starting as process 45440 ...
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: option '--innodb-large-prefix' requires an argument
2020-05-29 22:13:03 0 [ERROR] Parsing options for plugin 'InnoDB' failed.
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-29 22:13:03 0 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/usr/local/var/mysql for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/local/Cellar/mariadb/10.4.13/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
I noticed that the system can not chown for auth_pam_tool because Operation not permitted.
auth_pam_tool permission
this is my permission the directory.
% ls -l /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
-r-xr-xr-x 1 shingo staff 13608 5 10 04:28 /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
How to fix Operation not permitted?
Or is there any other reason why it cannot be installed?
Self resolved.
Anyway I gave it try start
Even though the installation was not successful, anyway I gave it try % mysql.server start.
A error log file was created.
A error log file was created by starting mysql server.
the error log shows:
2020-05-30 8:47:10 0 [Warning] InnoDB: innodb_open_files 300 should not be greater than the open_files_limit 256
2020-05-30 8:47:10 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-30 8:47:10 0 [ERROR] Aborting
An unknown value in the mysqlx-bind-address seems to be causing the error.
How to fix unknown variable
I found
the same error question. This question discussed a my.conf file.
~/.my.conf did not exist on my mac
/etc/my.conf did not exist on my mac
this question teach me the my.conf location.
Finally I found my.conf in /usr/local/etc/my.cnf.Certainly the settings for mysqlx-bind-address were written in my.conf.
So rm /usr/local/etc/my.cnf, then brew reinstall SUCCESS!.
The permission was irrelevant at all.
this work for me:
rm /opt/homebrew/etc/my.cnf
I'm trying to set up Wordpress with this documentation:
https://github.com/bitnami/bitnami-docker-wordpress#mount-host-directories-as-data-volumes-with-docker-compose
My host directories for the volumes look like this in the docker-compose file:
volumes:
- './mariadb_data:/bitnami'
...
volumes:
- './wordpress_data:/bitnami'
When running docker-compose up, the following errors occur:
mariadb_1 | INFO ==> Starting mysqld_safe...
mariadb_1 | Could not open required defaults file: /opt/bitnami/mariadb/conf/my.cnf
mariadb_1 | Fatal error in defaults handling. Program aborted
mariadb_1 | WARNING: Defaults file '/opt/bitnami/mariadb/conf/my.cnf' not found!
mariadb_1 | Could not open required defaults file: /opt/bitnami/mariadb/conf/my.cnf
mariadb_1 | Fatal error in defaults handling. Program aborted
mariadb_1 | WARNING: Defaults file '/opt/bitnami/mariadb/conf/my.cnf' not found!
mariadb_1 | 171105 05:15:41 mysqld_safe Logging to '/opt/bitnami/mariadb/data/200101d1b330.err'.
mariadb_1 | 171105 05:15:41 mysqld_safe Starting mysqld daemon with databases from /opt/bitnami/mariadb/data
mariadb_1 | /opt/bitnami/mariadb/bin/mysqld_safe_helper: Can't create/write to file '/opt/bitnami/mariadb/data/200101d1b330.err' (Errcode: 2 "No such file or directory")
myproject_mariadb_1 exited with code 1
However, if I change my docker-compose file to use non-host directories:
volumes:
- 'mariadb_data:/bitnami'
...
volumes:
- 'wordpress_data:/bitnami'
... the docker-compose up works.
If I then stop docker, and then revert my docker-compose file to use host directories again, docker-compose up will now work, and the host directories are populated correctly.
This is a solution to my problem, but I would like to know why, and if there is a way to make things work without this work-around.
Check if the bitnami/bitnami-docker-mariadb issue 123 is relevant in your case:
It seems that docker-compose up did not create a container from scratch (with a clean filesystem), but instead used one preexisting. I deduce this from the beginning sequence:
Starting mariadb_mariadb_1
Attaching to mariadb_mariadb_1
...
It seems to me that this container, in its previous execution, was started with an attached volume at /bitnami/mariadb. After that, the container was stopped, such volume detached, and then the container was restarted. It didn't configure anything and just tried to run the mysql server binary. Since we perform symbolic links from /opt/bitnami/mariadb pointing to /bitnami/mariadb (my.cnf file included), that file went missing and the binaries crashed at start time.
Could you please try using the docker-compose file we provide in this repo? If you only modify it for adding environment variables you shouldn't run into these kind of issues.
As a workaround, just run the following:
docker-compose down -v
docker-compose up
It will remove the the MariaDB container, along with any volume associated, and start from scratch. Bear in mind that you will lose any state you set in the container.
I have installed riak (apt-get) on an EC2 instance, lucid, amd64 with libssl.
When running riak start I get:
Attempting to restart script through sudo -H -u riak
Riak failed to start within 15 seconds,
see the output of 'riak console' for more information.
If you want to wait longer, set the environment variable
WAIT_FOR_ERLANG to the number of seconds to wait.
Running riak console:
Exec: /usr/lib/riak/erts-5.9.1/bin/erlexec -boot /usr/lib/riak/releases/1.3.1/riak
-embedded -config /etc/riak/app.config
-pa /usr/lib/riak/lib/basho-patches
-args_file /etc/riak/vm.args -- console
Root: /usr/lib/riak
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:2:2] [async-threads:64] [kernel-poll:true]
/usr/lib/riak/lib/os_mon-2.2.9/priv/bin/memsup: Erlang has closed.
Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,riak_core, {shutdown,{riak_core_app,start,[normal,[]]}}}"}
Crash dump was written to: /var/log/riak/erl_crash.dump
Kernel pid terminated (application_controller) ({application_start_failure,riak_core, {shutdown,{riak_core_app,start,[normal,[]]}}})
The error logs:
2013-04-24 11:36:20.897 [error] <0.146.0> CRASH REPORT Process riak_core_handoff_listener with 1 neighbours exited with reason: bad return value: {error,eaddrinuse} in gen_server:init_it/6 line 332
2013-04-24 11:36:20.899 [error] <0.145.0> Supervisor riak_core_handoff_listener_sup had child riak_core_handoff_listener started with riak_core_handoff_listener:start_link() at undefined exit with reason bad return value: {error,eaddrinuse} in context start_error
2013-04-24 11:36:20.902 [error] <0.142.0> Supervisor riak_core_handoff_sup had child riak_core_handoff_listener_sup started with riak_core_handoff_listener_sup:start_link() at undefined exit with reason shutdown in context start_error
2013-04-24 11:36:20.903 [error] <0.130.0> Supervisor riak_core_sup had child riak_core_handoff_sup started with riak_core_handoff_sup:start_link() at undefined exit with reason shutdown in context start_error
I'm new to Riak and basically tried to run through the "Fast Track" docs.
None of the default core IP settings in the configs have been changed. They are still set to {http, [ {"127.0.0.1", 8098 } ]}, {handoff_port, 8099 }
Any help would be greatly appreciated.
I know this is old but there is some solid documentation about the errors in the crash.dump file on the Riak site.
I'm preparing to use nginx/uwsgi with flask for a website i'm developing, but i'm running into problems. NB the website itself runs great using flask's debug :5000 port, but i want to go into production now. To explain what i did.
It's a linode ubuntu 12.04LTS server, I installed it like this:
# install nginx
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:nginx/stable
sudo apt-get update
sudo apt-get upgrade --show-upgraded
sudo apt-get install nginx-full
# installing uwsgi
sudo apt-get install build-essential python-dev libxml2-dev
sudo apt-get install libc6 libexpat1 libgd2-xpm libgeoip1 libpam0g libpcre3 libssl1.0.0 libxml2 libxslt1.1 zlib1g
sudo pip install uwsgi
# python basics
sudo apt-get install python-pip build-essential python-dev
sudo pip install virtualenv
sudo pip install virtualenvwrapper
sudo mkdir -p /srv/www/li/
cd /srv/www/li/
virtualenv venv
source /srv/www/li/venv/bin/activate
pip install flask
Then i set out to configure everything, but I already run into trouble with uwsgi (never mind NGINX, which will be the next step.
sudo nano /etc/uwsgi/apps-available/li.xml
<uwsgi>
<plugin>python</plugin>
<socket>/run/uwsgi/app/li.socket</socket>
<chmod-socket>666</chmod-socket>
<chdir>/srv/www/li</chdir>
<pythonpath>/srv/www/li</pythonpath>
<virtualenv>/srv/www/li/venv</virtualenv>
<module>li</module>
<wsgi-file>/srv/www/li/li.py</wsgi-file>
<callable>app</callable>
<master/>
<processes>4</processes>
<harakiri>60</harakiri>
<reload-mercy>8</reload-mercy>
<cpu-affinity>1</cpu-affinity>
<stats>/tmp/stats.socket</stats>
<max-requests>2000</max-requests>
<limit-as>512</limit-as>
<reload-on-as>256</reload-on-as>
<reload-on-rss>192</reload-on-rss>
<no-orphans/>
<vacuum/>
</uwsgi>
sudo ln -s /etc/uwsgi/apps-available/li.xml /etc/uwsgi/apps-enabled/li.xml
However if i run it, i get:
uwsgi --xml /etc/uwsgi/apps-enabled/li.xml
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml
open("./python_plugin.so"): No such file or directory [core/utils.c line 4755]
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 16:30:53 2013] ***
compiled with version: 4.6.3 on 28 February 2013 12:38:22
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013
nodename: demo
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /run/uwsgi/app
detected binary path: /usr/local/bin/uwsgi
your processes number limit is 63594
limiting address space of processes...
your process address space limit is 536870912 bytes (512 MB)
your memory page size is 4096 bytes
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers ***
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /run/uwsgi/app/li.socket fd 3
Python version: 2.7.3 (default, Aug 1 2012, 05:25:23) [GCC 4.6.3]
Set PythonHome to /srv/www/li/venv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0xa86e20
your server socket listen backlog is limited to 100 connections
mapped 362120 bytes (353 KB) for 4 cores
*** Operational MODE: preforking ***
added /srv/www/li/ to pythonpath.
/srv/www/li/venv/local/lib/python2.7/site-packages/mongoengine/fields.py:744: FutureWarning: ReferenceFields will default to using ObjectId strings in 0.8, set DBRef=True if this isn't desired
warnings.warn(msg, FutureWarning)
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xa86e20 pid: 14934 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 14934)
spawned uWSGI worker 1 (pid: 14940, cores: 1)
mapping worker 1 to CPUs: 0
spawned uWSGI worker 2 (pid: 14941, cores: 1)
mapping worker 2 to CPUs: 1
spawned uWSGI worker 3 (pid: 14942, cores: 1)
mapping worker 3 to CPUs: 2
spawned uWSGI worker 4 (pid: 14943, cores: 1)
unlink(): Operation not permitted [core/socket.c line 109]
bind(): Address already in use [core/socket.c line 141]
...brutally killing workers...
mapping worker 4 to CPUs: 3
VACUUM: unix socket /run/uwsgi/app/li.socket removed.
So i get the unlink operation not permitted and the bind address already in use errors (next to the python_plugin error of which i also have no clue how to solve that!). If i run as sudo, it seems to work fine ->
sudo uwsgi --xml /etc/uwsgi/apps-enabled/li.xml
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml
open("./python_plugin.so"): No such file or directory [core/utils.c line 4755]
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!!
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 15:47:41 2013] ***
compiled with version: 4.6.3 on 28 February 2013 12:38:22
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013
nodename: demo
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /run/uwsgi
detected binary path: /usr/local/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
your processes number limit is 63594
limiting address space of processes...
your process address space limit is 536870912 bytes (512 MB)
your memory page size is 4096 bytes
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers ***
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uwsgi socket 0 bound to UNIX address /run/uwsgi/app/li.socket fd 3
Python version: 2.7.3 (default, Aug 1 2012, 05:25:23) [GCC 4.6.3]
Set PythonHome to /srv/www/li/venv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1fc9d00
your server socket listen backlog is limited to 100 connections
mapped 362120 bytes (353 KB) for 4 cores
*** Operational MODE: preforking ***
added /srv/www/li/ to pythonpath.
/srv/www/li/venv/local/lib/python2.7/site-packages/mongoengine/fields.py:744: FutureWarning: ReferenceFields will default to using ObjectId strings in 0.8, set DBRef=True if this isn't desired
warnings.warn(msg, FutureWarning)
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1fc9d00 pid: 14755 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 14755)
spawned uWSGI worker 1 (pid: 14761, cores: 1)
mapping worker 1 to CPUs: 0
spawned uWSGI worker 2 (pid: 14762, cores: 1)
mapping worker 2 to CPUs: 1
spawned uWSGI worker 3 (pid: 14763, cores: 1)
mapping worker 3 to CPUs: 2
spawned uWSGI worker 4 (pid: 14764, cores: 1)
*** Stats server enabled on /tmp/stats.socket fd: 16 ***
mapping worker 4 to CPUs: 3
Can anyone please help me? As www-data is in the www-data group and he runs it, I tried some stuff:
sudo usermod -a -G www-data $USER
sudo chown -R $USER:www-data /srv/www/li
sudo chmod -R g+r+w+x /srv/www/li
sudo chown -R $USER:www-data /etc/uwsgi/apps-enabled
sudo chmod -R g+r+w+x /etc/uwsgi/apps-enabled
sudo chown -R $USER:www-data /run/uwsgi/app
sudo chmod -R g+r+w+x /run/uwsgi/app
But that really didn't help either. I also tried a tcp port instead of the unix /run/uwsgi/app/ port that didn't make any difference either...
This is driving me crazy :( I hope someone has a clue on what's happening here.
Kind regards,
Carst
edit: after a server restart it still gives an erro but a different one:
geoadmin#demo:~$ uwsgi --xml /etc/uwsgi/apps-enabled/li.xml
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 18:47:36 2013] ***
compiled with version: 4.6.3 on 28 February 2013 12:38:22
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013
nodename: demo
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /home/geoadmin
detected binary path: /usr/local/bin/uwsgi
your processes number limit is 63594
limiting address space of processes...
your process address space limit is 536870912 bytes (512 MB)
your memory page size is 4096 bytes
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers ***
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
bind(): No such file or directory [core/socket.c line 141]
This was consistently my #1 result on google, and this page was relatively unhelpful to me, so I'm going to add my answer, even though it's fairly obvious in retrospect.
My problem was a permissions problem with my stats socket. If you change your uWSGI config's uid or gid parameters, make sure you either chmod or rm all of your old sockets/ pids, and their parent folders.
In my case I was trying to place the .sock file in the /vagrant directory, which is a machine mounted folder of virtual box and is not good for much more than reads and writes.
Place the .sock file outside of a virtualbox mount-point preferably in /tmp The FHS says: /var/run
Ref:
https://stackoverflow.com/a/7580524/1695680
Ok, after the later edit i checked the directories and the socket directory didnt exist (anymore); i think it had to do with the original apt-get install versus my later pip install... still have the issue with the python plugin but will check if it's necessary for nginx or if it will work without it... 8 hours of work over a reset, d'oh ;)
#bearrito:
In the end I put the socket in the tmp directory to avoid rights issues:
<uwsgi>
<uid>www-data</uid>
<gid>www-data</gid>
<plugin>python</plugin>
<socket>/tmp/li.socket</socket>
<chmod-socket>666</chmod-socket>
<chdir>/srv/www/li</chdir>
<pythonpath>/srv/www/li</pythonpath>
<virtualenv>/srv/www/li/venv</virtualenv>
<module>li</module>
<wsgi-file>/srv/www/li/li.py</wsgi-file>
<callable>app</callable>
<master/>
<processes>2</processes>
<pidfile>/tmp/li.pid</pidfile>
<harakiri>120</harakiri>
<reload-mercy>8</reload-mercy>
<cpu-affinity>1</cpu-affinity>
<stats>/tmp/stats.socket</stats>
<max-requests>2000</max-requests>
<limit-as>2048</limit-as>
<reload-on-as>2048</reload-on-as>
<reload-on-rss>1024</reload-on-rss>
<no-orphans/>
<vacuum/>
</uwsgi>
I hope this helps!
For me the solution was to remove /var/run/uwsgi/.sock and
chmod 775 /var/run/uwsgi
chmod 777 /var/log/uwsgi
or wherever your uwsgi files are.