I'm using nginx on OS X 10.8. Freshly installed nginx but can't find a way to restart nginx except kill nginx_pid say kill 64116. Wondering if there are better ways to restart nginx.
Found some methods on Google and SO but didn't work:
nginx -s restart
sudo fuser -k 80/tcp ; sudo /etc/init.d/nginx restart
The error message for nginx -s restart is
nginx: [error] open() "/usr/local/var/run/nginx.pid" failed (2: No such file or directory)
Sometimes also get this error msg:
nginx: invalid option: "-s restart"
Try running sudo nginx before starting nginx.
To reload config files:
sudo nginx -s reload
To fully restart nginx:
sudo nginx -s quit
sudo nginx
Details
There is no restart signal for nginx. From the docs, here are the signals that the master process accepts:
SIGINT, SIGTERM Shut down quickly.
SIGHUP Reload configuration, start the new worker process with a new configuration, and gracefully shut down old worker processes.
SIGQUIT Shut down gracefully.
SIGUSR1 Reopen log files.
SIGUSR2 Upgrade the nginx executable on the fly.
SIGWINCH Shut down worker processes gracefully.
Presumably you could send these signals to the process id manually, but the nginx command has the flag nginx -s <signal> that sends signals to the master process for you. Your options are:
stop SIGTERM
quit SIGQUIT
reopen SIGUSR1
reload SIGHUP
No need to futz with the pid manually.
Edit: just realized much of this info was already in comments on the other answers. Leaving this here anyway to summarize the situation.
What is your nginx pid file location? This is specified in the configuration file, default paths specified compile-time in the config script. You can search for it as such:
find / -name nginx.pid 2>/dev/null (must issue while nginx is running)
Solution:
sudo mkdir -p /usr/local/var/run/
ln -s /current/path/to/pid/file /usr/local/var/run/nginx.pid
$ sudo nginx -c /usr/local/etc/nginx/nginx.conf
$ sudo nginx -s reload
Source Link: https://blog.csdn.net/github_33644920/article/details/51733436
Try this:
sudo nginx -s stop
followed by a:
sudo nginx
It seems that nginx keeps track of its state, to if you stop it twice, it will complain. But the above worked for me.
I do it like this:
First kill the progress
ps aux | grep nginx
kill -9 {pid}
Then start nginx
nginx
It works!
As a future resource, you can consult http://wiki.nginx.org/CommandLine
Nginx probably runs as root, so you will need to run a variant of the following command to affect it.
sudo nginx -s stop | reload | quit | reopen
There is usually not much reason to restart Nginx like Apache would need. If you have modified a configuration file, you may just want to the reload option.
check if this directory exists:
/usr/local/var/run
this error can occurs when nginx try to initialise pid file in
localisation that doesn't exist.
There is a bug here. Depending on whether nginx is running while you modify/restart apache and/or modify nginx configs it is possible for this file (which is essentially just a process ID pointer) to be destroyed.
When you attempt to send any signal to nginx like
nginx -s quit;
nginx -s stop;
nginx -s reload;
nginx uses this file to reference the ID of the process to which it needs to send the signal. If the file isn't there the link between the active running process of nginx & the cli app is effectively broken.
I actually ended up in a state where two nginx processes were running simultaneously so killed both.
To work around this, you can either Force the termination of existing nginx processes via Activity Monitor (then run nginx & have the cli app create a new nginx.pid file) or if you REALLY need to keep nginx running but want to run nginx -s reload - manually create a file in the /run path called nginx.pid and insert the PID of the currently running nginx processs (obtained via Activity Monitor).
To reload the custom config file use
nginx -s reload -c /etc/nginx/conf.d/<config file>.conf
This could simply mean that nginx is already stopped - not running at the moment.
First, confirm whether nginx is running, execute:
$ ps aux | grep nginx
i got the same error link you, i tried many way to fix it but it not working
after that i run the command line and it work well:
nginx -c /usr/local/etc/nginx/nginx.conf
the information i got from here
https://blog.csdn.net/wn1245343496/article/details/77974756
One way to stop or reload is through the below command,
For stop:
sudo /usr/local/nginx/sbin/nginx -s stop
Run reload only if the nginx is running:
sudo /usr/local/nginx/sbin/nginx -s reload
By doing like the above, you wont get nginx: [error] open() "/usr/local/var/run/nginx.pid" this issue
Related
I have a Docker container running a UWSGI server that's serving an API built in Python using Flask, which has the command ENTRYPOINT ["./startapi.sh"] to start up the server when the container is built. The container uses nginx as a reverse proxy to handle requests and serve them to the API inside the UWSGI instance.
startapi.sh contains the following:
#!/bin/bash
service nginx start
exec uwsgi --ini uwsgi.ini &
while :; do nginx -s reload; sleep 6h; done
However, when I try to docker stop the container, it waits the full 10s before sending SIGKILL to the container because PID 1 inside the container is /bin/bash ./startapi.sh. I know why--because the SIGTERM that docker stop sends doesn't reach the UWSGI instance, as it is not PID 1.
I know how to resolve that--just remove the & from the end of exec uwsgi in startapi.sh--but then the while loop won't run because it follows the exec uwsgi command (at least, I don't see the loop when I run docker exec -it container.name ps auxww from the host). Swapping the two lines (putting the while loop before the exec uwsgi) will properly run the sleep command to reload nginx, but will fail to run exec uwsgi and therefore not launch the API.
My dilemma, thus, is this--I want PID 1 in my container to be uwsgi --ini uwsgi.ini so that docker stop gracefully stops the UWSGI server (and yes, I do have hook-master-start = unix_signal:15 gracefully_kill_them_all in my uwsgi.ini per a UWSGI GitHub issue, so it should comply with docker stop SIGTERM), but I also want to be able to reload nginx automatically every 6hrs via the while loop/sleep one-liner.
Is there something I can do to achieve that?
So swap them. Literally. Run the loop in the background.
#!/bin/bash
service nginx start
while :; do nginx -s reload; sleep 6h; done &
exec uwsgi --ini uwsgi.ini
But really, you should be running supervisord instead.
Also, consider inotifywait and executing nginx -s reload when the config changed.
I am facing the problem to add/change attributes of the slave machines in the DCOS environment.
After changing attributes in
vi /var/lib/dcos/mesos-slave-common
MESOS_ATTRIBUTES=TYPE:DB;DB_TYPE:MONGO;
file, it not immediately getting updated in the cluster.
I have to run the following commands
systemctl stop dcos-mesos-slave
rm -f /var/lib/mesos/slave/meta/slaves/latest
systemctl start dcos-mesos-slave
This means essentially I have to restart the service in the slave.
And the slave is down for at least 1 hour,
Is there any other way achieve this?
As variant we are using some hack, we create /var/lib/dcos/mesos-slave-common file and "froze" it by changing access right, like:
echo "MESOS_ATTRIBUTES=TYPE:DB;DB_TYPE:MONGO;" | sudo tee /var/lib/dcos/mesos-slave-common
sudo chmod -w /var/lib/dcos/mesos-slave-common
# And after that you can execute node installation. Ugly, but that is working :)
sudo dcos_install.sh slave
If I connect to a docker container
$> docker exec -it my_container zsh
and inside it I want to kill something I started with ctrl+c I noticed that it takes forever to complete. I've googled around and it seems that ctrl+c works a bit different than you would expect. My question, how can I fix ctrl+c inside a container ?
The problem is that Ctrl-C sends a signal to the top-level process inside the container, but that process doesn't necessarily react as you would expect. The top-level process has ID 1 inside the container, which means that it doesn't get the default signal handlers that processes usually have. If the top-level process is a shell, then it can receive the signal through its own handler, but doesn't forward it to the command that is executed within the shell. Details are explained here. In both cases, the docker container acts as if it simply ignores Ctrl-C.
Starting with docker 0.6.5, you can add -t to the docker run command, which will attach a pseudo-TTY. Then you can type Control-C to detach from the container without terminating it.
If you use -t and -i then Control-C will terminate the container. When using -i with -t then you have to use Control-P Control-Q to detach without terminating.
Test 1:
$ ID=$(sudo docker run -t -d ubuntu /usr/bin/top -b)
$ sudo docker attach $ID
Control-P Control-Q
$ sudo docker ps
The container is still listed.
Test 2:
$ ID=$(sudo docker run -t -i -d ubuntu /usr/bin/top -b)
$ sudo docker attach $ID
Control-C
$ sudo docker ps
the container is not there (it has been terminated). If you type Control-P Control-Q instead of Control-C in the 2nd example, the container would still be running.
Wrap the program with a docker-entrypoint.sh bash script that blocks
the container process and is able to catch ctrl-c. This bash example
might help:
https://rimuhosting.com/knowledgebase/linux/misc/trapping-ctrl-c-in-bash
#!/bin/bash
# trap ctrl-c and call ctrl_c()
trap ctrl_c INT
function ctrl_c() {
echo "** Trapped CTRL-C"
}
for i in `seq 1 5`; do
sleep 1
echo -n "."
done
Use Ctrl+\ instead of Ctrl+C
it kills the process instead of politely asking it to shut down.(read more here.)
In some cases, when I used ctrl-C to terminate a process inside a container, the container terminates.
Additionally, I've seen cases where processes running inside containers leave zombie processes.
I have found that when starting a container with the --init switch, both of these problems are addressed. This appears to make my containers operate in a more "normal, expected UNIX-like manner".
Note: --init is different from -i, which is short for --interactive
If you want more information on what the --init switch does, please read up on it on the Docker web pages that include information on docker run. The information on that web page says "Run an init inside the container that forwards signals and reaps processes".
I had the similar problem when I was trying to run mdbook (the Rust executable) in the docker container. The mdbook starts simple webserver and I want to stop it via Ctrl+C which did not work.
$ docker -ti --rm -p 4321:4321 my-docker-image mdbook serve --hostname 0.0.0.0 --port 4321
2019-08-16 14:00:11 [INFO] (mdbook::book): Book building has started
2019-08-16 14:00:11 [INFO] (mdbook::book): Running the html backend
2019-08-16 14:00:11 [INFO] (mdbook::cmd::serve): Serving on: http://0.0.0.0:4321
2019-08-16 14:00:11 [INFO] (ws): Listening for new connections on 0.0.0.0:3001.
2019-08-16 14:00:11 [INFO] (mdbook::cmd::watch): Listening for changes...
^C^C
Be inspired by #NID's answer I encapsulated the mdbook executable by universal bash script docker-entrypoint.sh which did the trick (without the need to explicitly catch the INT signal).
$ docker -ti --rm -p 4321:4321 my-docker-image docker-entrypoint.sh mdbook serve --hostname 0.0.0.0 --port 4321
2019-08-16 14:00:11 [INFO] (mdbook::book): Book building has started
2019-08-16 14:00:11 [INFO] (mdbook::book): Running the html backend
2019-08-16 14:00:11 [INFO] (mdbook::cmd::serve): Serving on: http://0.0.0.0:4321
2019-08-16 14:00:11 [INFO] (ws): Listening for new connections on 0.0.0.0:3001.
2019-08-16 14:00:11 [INFO] (mdbook::cmd::watch): Listening for changes...
^C $
The content of the docker-entrypoint.sh is very simple:
#!/bin/bash
$#
I tried the --init solution by #Remy Orange and it worked for me. After some searching, including i)How to use --init parameter in docker run, ii) What is advantage of Tini? and iii) init, I wrote the detailed solution below:
Install tini on Ubuntu:
via launching:
$ sudo apt update && sudo apt install tini
Or, if tini is not available in your distribution or is too old, please check a Dockerfile to add tini at here.
Run your Docker container with --init:
docker run -ti --init --rm YOUR_DOCKER_CONTAINER_EXMAPLE bash
Then you come into your docker container and you can run some processes or experiments. E.g., run a Python code, then you can launch Ctrl + C to cancel this Python code, just as what you can do on Ubuntu (i.e., the regular terminal which is outside the docker container).
See the screenshot in my case:
launching Ctrl + C (i.e., ^C) to cancel the python process:
It stops, showing KeyboardInterrupt as expected:
when your docker terminal is not responding to Ctrl+C/Ctrl+D/Ctrl+/, try these steps:
#1>> Open another terminal session and enter the command:
**`docker container ls`**
or
**`docker container list`**
#2>> locate the container id from the above list and issue the docker container stop command:
**`docker stop <<containerId>>`**
#3>> next time when you launch the docker container, use the flag "**-it**" to respond to the Ctrl+C event
docker run -it <>
Now you can stop ,with control+C
If you use Docker Compose, you can add the init parameter to forward signals to the container:
version: "2.4"
services:
web:
image: alpine:latest
init: true
To make it work you need to have the option -ti in your docker exec command.
Wasted about 2 hours.
New commands -- (Working fine)
sudo docker stop
sudo docker rm
sudo docker run -t
Old commands -- (Not working anymore)
sudo docker stop
sudo docker rm
sudo docker run
Ctrl + C
sudo docker start
Hope that helps someone.
For me Ctrl+C works only after running a container with docker run -it <container id/name>
For whom still have this issue, worked for me the Ctrl+d. Neither Ctrl+c or Ctrl+z worked.
Running postgreSQL 9.4.5_2 currently
I have tried
pg_ctl stop -W -t 1 -s -D /usr/local/var/postgres -m f
Normally no news is good news but after I will run
pg_ctl status -D /usr/local/var/postgres
and get pg_ctl: server is running (PID: 536)
I have also tried
pg_ctl restart -w -D /usr/local/var/postgres -c -m i
Response message is:
waiting for server to shut down.......................... failed
pg_ctl: server does not shut down
I've also checked my /Library/LaunchDaemons/ to see why the service is starting at login but no luck so far. Anyone have any ideas on where I should check next? Force quit in the activity monitor also isn't helping me any.
Sadly none of the previous answers help me, it worked for me with:
brew services stop postgresql
Cheers
I tried various options; finally, the below command worked.
sudo -u postgres ./pg_ctl -D /your/data/directory/path stop
example
sudo -u postgres ./pg_ctl -D /Library/PostgreSQL/11/data stop
As per the comments, the recommended command is without the ./ when calling pg_ctl:
sudo -u postgres pg_ctl -D /Library/PostgreSQL/11/data stop
Tried sudo and su but no such luck.
Just found this gui
https://github.com/MaccaTech/postgresql-mac-preferences
If anyone can help with the terminal commands that would be very much appreciated, but till then the gui will get the job done.
Had the same issue, I had installed postgres locally and wanted to wrap in a docker container instead.
I solved it pretty radically by 1) uninstalling postgres 2) kill the leftover process on postgres port. If you don't un-install the process restarts and grabs the port again - look at your Brewfile form brew bundle dump to check for a restart_service: true flag.
I reasoned that, as I am using containers, I should not need the local one anyway, but !! attention this will remove postgres from your system.
brew uninstall postgres
...
lsof -i :5432 # this to find the PID for the process
kill - 9 <the PID you found at previous command>
Note: if you still want to used psql you can brew install libpq, and add psql to your PATH (the command output shows you what to add to your .zshrc, or similar)
you can stop the server using this command
{pg_ctl -D /usr/local/var/postgres stop -s -m fast}
Adding onto the solutions already stated :
if you decide to use the pg_ctl command, ensure that you are executing the command as a user with the permissions to access the databases/database server.
this means :
the current logged in user on your terminal should have those permissions
or
first run :
$ sudo su <name_of_database_user>
pg_ctl -D /Library/PostgreSQL/<version_here>/data/ stop
the same goes for the start command.
credit : https://gist.github.com/kingbin/9435292
(essentially hosted a file with the commands on github, saved me some time :^) )
I had a stray docker container running Postgres that I had forgotten about.
How can I tell if my Postgresql server is running or not?
I'm getting this message:
[~/dev/working/sw] sudo bundle exec rake db:migrate
rake aborted!
could not connect to server: Connection refused
Is the server running on host "localhost" and accepting
TCP/IP connections on port 5432?
Update:
> which postgres
/usr/local/bin/postgres
> pg_ctl -D /usr/local/bin/postgres -l /usr/local/bin/postgres/server.log start
pg_ctl: could not open PID file "/usr/local/bin/postgres/postmaster.pid": Not a directory
Update 2:
>pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
server starting
sh: /usr/local/var/postgres/server.log: No such file or directory
The simplest way to to check running processes:
ps auxwww | grep postgres
And look for a command that looks something like this (your version may not be 8.3):
/Library/PostgreSQL/8.3/bin/postgres -D /Library/PostgreSQL/8.3/data
To start the server, execute something like this:
/Library/PostgreSQL/8.3/bin/pg_ctl start -D /Library/PostgreSQL/8.3/data -l postgres.log
You can run the following command to determine if postgress is running:
$ pg_ctl status
You'll also want to set the PGDATA environment variable.
Here's what I have in my ~/.bashrc file for postgres:
export PGDATA='/usr/local/var/postgres'
export PGHOST=localhost
alias start-pg='pg_ctl -l $PGDATA/server.log start'
alias stop-pg='pg_ctl stop -m fast'
alias show-pg-status='pg_ctl status'
alias restart-pg='pg_ctl reload'
To get them to take effect, remember to source it like so:
$ . ~/.bashrc
Now, try it and you should get something like this:
$ show-pg-status
pg_ctl: server is running (PID: 11030)
/usr/local/Cellar/postgresql/9.2.4/bin/postgres
As of PostgreSQL 9.3, you can use the command pg_isready to determine the connection status of a PostgreSQL server.
From the docs:
pg_isready returns 0 to the shell if the server is accepting connections normally, 1 if the server is rejecting connections (for example during startup), 2 if there was no response to the connection attempt, and 3 if no attempt was made (for example due to invalid parameters).
You probably did not init postgres.
If you installed using HomeBrew, the init must be run before anything else becomes usable.
To see the instructions, run brew info postgres
# Create/Upgrade a Database
If this is your first install, create a database with:
initdb /usr/local/var/postgres -E utf8
To have launchd start postgresql at login:
ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents
Then to load postgresql now:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
Or, if you don't want/need launchctl, you can just run:
pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
Once you have run that, it should say something like:
Success. You can now start the database server using:
postgres -D /usr/local/var/postgres or
pg_ctl -D /usr/local/var/postgres -l logfile start
If you are still having issues, check your firewall. If you use a good one like HandsOff! and it was configured to block traffic, then your page will not see the database.
It depends on where your postgresql server is installed. You use the pg_ctl to manually start the server like below.
pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
You can use brew to start/stop pgsql. I've following short cuts in my ~/.bashrc file
alias start-pg='brew services start postgresql'
alias stop-pg='brew services stop postgresql'
alias restart-pg='brew services restart postgresql'
The pg_ctl status command suggested in other answers checks that the postmaster process exists and if so reports that it's running. That doesn't necessarily mean it is ready to accept connections or execute queries.
It is better to use another method like using psql to run a simple query and checking the exit code, e.g. psql -c 'SELECT 1', or use pg_isready to check the connection status.