I am accessing my raspberry pi 3 from ssh. Can you tell me how to shut it down from ssh. Whenever I use sudo shutdown -h now the terminal just freezes without any output. If I kill the terminal I can ssh into raspberry again showing it did not shut down.
Add the -P flag:
sudo shutdown -h -P now
sudo shutdown -h now or sudo halt
You can’t use shutdown (or halt) unless you have sudo privileges.
-h instructs to halt the system, now means to run command right now. You can add a number X to tell it to shut down in X minutes. It also allows a specific time in this format XX:XX (note this is in 24 hour format seperated by a : colon).
sudo halt should be help you in this case
Just run sudo halt and wait until the green light turns off to power it off.
If you're on Linux, you should try:
sudo shutdown -h now && exit
A solution is to launch the shutdown in the background, with some delay to allow the user to safely exit the ssh connection.
Something like this :
{(sleep 5; sudo halt;) &}; exit
I created as script to suspend or shutdown a remote host over ssh. This may be used to suspend / shutdown a remote computer without an interactive session and yet not keep a terminal busy. You will need to give permissions to the remote user to shutdown / suspend using sudo without a password. Additionally, the local and remote machines should be set up to SSH without an interactive login. The script is more useful for suspending the machine as a suspended machine will not disconnect the terminal.
local_user#hostname:~$ ssh remote_user#remote_host "screen -d -m sudo pm-suspend"
source: कार्यशाला (Kāryaśālā)
Use the command systemctl poweroff
You will then be asked to authenticate yourself and enter your password. For reasons I don't know, it asks you to enter your password a second time.
Once authenticated, enter poweroff and the pi will shutdown.
Related
I'm running VS Code on Windows, and SSH into a Ubuntu machine.
Executing killall node and sending the command to the remote machine causes the local VS Code instance to require restart - Presumably to rebind the SSH connection locally(?).
This is bad for workflow.
Is there a better way to kill all node processes on the remote machine without destroying VD Code requiring to reconnect?
lsof -i -P -n | grep LISTEN reveals that we might be able to get away with just killing IPv6-bound processes - Can these be targeted as a group (Somehting like killall node ipv6)?
A note that killall node is the only way ensure the node process is killed and a port conflict doesn't arise. Every other conceivable method, kill -9 on the process etc, both on the command line and in the code base through SIGINT have been tried.
Suggesting to try commands pkill and learn about pgrep on remote machine.
pkill -9 -f node
Also suggesting to write a bash script:
nodes_killer
#!/bin/bash
killall node
Than give nodes_killer execution permissions
chmod a+x nodes_killer
Than try to call nodes_killer remotely.
This might guard your VSC from the killall command.
Normally, when the command to start server is given as pg_ctl.exe -D ..\data -o"-p8028 -w start", the server waits until startup gets completed.
But my scenario is, I had forcefully shutdown the server using the -m immediate option. Then I tried to start the server with the command pg_ctl.exe -D ..\data -o"-p8028" -w start. While starting the server after immediate shutdown, it will move into the recovery mode.
So my question is, while starting the postgres server after immediate shutdown with the command pg_ctl.exe -D ..\data -o"-p8028" -w start, whether it will wait for the recovery mode to complete or not?
I found out that, even when we start the PostgreSQL server with the command
pg_ctl.exe -D ..\data -o"-p8028" -w start
it will not wait until the recovery mode is complete. It will wait for the time that we have specified during startup.
I have the following code that enables logical decoding in PostgreSQL 9.4:
pg_recvlogical -h localhost --slot test_slot --create-slot
pg_recvlogical -h localhost --slot test_slot --start -f -
I spawn a node.js subprocess to run this code and listen for changes however I'm unsure of what the correct procedure is to terminate the connection. I usually just CNTRL+C from the command line or kill the subprocess in code but I always get a pg_recvlogical: unexpected termination of replication stream: error. What is the correct way to terminate this connection?
The PostgreSQL documentation says,
--start
Begin streaming changes from the logical replication slot specified by --slot, continuing until terminated by a signal. If the server side change stream ends with a server shutdown or disconnect, retry in a loop unless --no-loop is specified.
So I assume the standard Linux signals meanings apply. Therefore, SIGINT or SIGQUIT should be acceptable, giving the app time to finish.
What I do is I send SIGINT, then enter a loop, check if /proc/$PID_/stat exists, and after custom timeout, I send it SIGKILL, and wait $PID_ for it.
kill -2 $PID_
for i in `seq 1 8`; do
if [ ! -f /proc/$PID_/stat ] ; then
RETURN_CODE=`wait $PID_`;
break;
fi
sleep 1;
done
if [ -f /proc/$PID_/stat ] ; then
kill -9 $PID_;
RETURN_CODE=`wait $PID_`;
fi
This is Bash, but any decent platform/language will have tools to do it.
Shortened, so there may be a bug :)
I did the following to kill a zombie active replication slot.
connect to the server where postgres is installed using CLI with ssh.
ssh -i <generated_security_key_name/path>.pem <username>#<hostIp>
once connected with the VM in your server. type following command to connect to postgres sql.
sudo -i -u <postgres-username>
you can go with psql which is a terminal-based front-end to PostgreSQL
psql
check the pid against your replication slot.
select * from pg_replication_slots;
Enter the following to kill it.
sudo kill <pid>
I want to run PostgreSQL 9.1 using Supervisor on Ubuntu 10.04. At the moment, I manually start PostgreSQL using the init script:
/etc/init.d/postgresql start
According to this post: http://nicksergeant.com/using-postgresql-with-supervisor-on-ubuntu-1010/, I need to modify the PostgreSQL config to make it run on TCP port instead of Unix socket, in order to make PostgreSQL work with Supervisor.
I have two questions regarding this approach:
Considering this is more of hack, is there any implication (e.g. security/permissions, performance, etc) of doing this?
Why cannot we just run the same init script postgresql in Supervisor config? Instead, as shown in the link above, it runs postmaster?
UPDATE:
Thanks to the useful suggestions from both answers below, I have setup a script for Supervisor to invoke PostgreSQL directly:
#!/bin/sh
# This script is run by Supervisor to start PostgreSQL 9.1 in foreground mode
if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
fi
exec su postgres -c "/usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf"
I also set the config: /etc/postgresql/9.1/main/start.conf to manual so that PostgreSQL does not start automatically on boot (however, it's not clear to me whether this config is loaded). And then I setup the Supervisor config for postgres as:
[program:postgres]
user=root
group=root
command=/usr/local/bin/run_postgresql.sh
autostart=true
autorestart=true
stderr_logfile=/home/www-data/logs/postgres_err.log
stdout_logfile=/home/www-data/logs/postgres_out.log
redirect_stderr=true
stopsignal=QUIT
So now, I can start PostgreSQL in supervisorctl by doing start postgres, which runs fine. However, after I issue stop postgres, although supervisorctl declares postgres is stopped, the server apparently is still running as I can psql into it.
I wonder if this is a Supervisor config issue, or a PostgreSQL issue. Any suggestion welcome!
The blog post is rather badly written. There is no "TCP mode": the post's suggested method will still listen on a Unix socket, just in a different directory. Comments in the post such as "external pid file - not needed for TCP mode" are very misleading.
postmaster is the traditional name for the postgresql executable (to distinguish the master dispatching process from the backend slaves). For some time now there has been no separate executable, and now it is installed as simply "postgres".
Assuming that Supervisor is broadly simliar to the qmail/daemontools supervise scheme, it would be entirely possible (in fact, quite normal) to have it run a script that sets up the directories and environment, and then execs postgres with the requisite arguments (or propagates arguments given to the wrapper script, which would be unusual with supervise but makes more sense when you have a config file to put arguments into).
The way supervise worked (and I'm going to continue to assume "Supervisor" is the same) is to have the supervisor process run a subprocess as specified, and simply relaunch a new subprocess if it exits. This is based on the idea that the process being launched is a long-lived daemon process that only exits when something goes badly wrong, and that simply restarting it is a valid fix. By contrast, init scripts such as in /etc/init.d run the subprocess and detach it, and return control to their caller- if the subprocess exits, nothing special happens, and it must be restarted manually. If you tried to simply run /etc/init.d/postgresql start from supervise, it would continuously keep spawning postgresql daemons, as the return from the init script would be interpreted as the daemon process having exited, when in fact it had been started and detached.
To avoid auto-starting the service with the /etc/init.d scripts, the package for postgresql 9.1 provides a file /etc/postgresql/9.1/main/start.conf that contains:
# Automatic startup configuration
# auto: automatically start/stop the cluster in the init script
# manual: do not start/stop in init scripts, but allow manual startup with
# pg_ctlcluster
# disabled: do not allow manual startup with pg_ctlcluster (this can be easily
# circumvented and is only meant to be a small protection for
# accidents).
auto
This is the file to modify to avoid auto-start as opposed to moving away /etc/init.d/postgresql as the blog post suggests.
Also, changing unix sockets parameters for lack of /var/run/postgresql doesn't look like the best idea, because it's the default for any program linked with libpq, and because there's no difficulty in creating that directory with the proper permissions, just like it's done by the package's start sequence in /usr/share/postgresql-common/init.d-functions:
# create socket directory
if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
fi
And although the default value shouldn't cause a problem, note that whether postmaster ultimately stays in foreground or forks and runs in background is controlled by the silent_mode parameter in postgresql.conf. Make sure that it is off.
I am trying to make both tomcat and postgres run under supervisor, and found some hints here : https://serverfault.com/questions/425132/controlling-tomcat-with-supervisor
Here is my modified run_postgresql.sh, using bash :
#!/bin/bash
# This script is run by Supervisor to start PostgreSQL 9.1 in foreground mode
function shutdown()
{
echo "Shutting down PostgreSQL"
pkill postgres
}
if [ -d /var/run/postgresql ]; then
chmod 2775 /var/run/postgresql
else
install -d -m 2775 -o postgres -g postgres /var/run/postgresql
fi
# Allow any signal which would kill a process to stop PostgreSQL
trap shutdown HUP INT QUIT ABRT KILL ALRM TERM TSTP
exec sudo -u postgres /usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main --config-file=/etc/postgresql/9.1/main/postgresql.conf
With this script postgresql stops correctly after supervisorctl stop postgres.
I have a capistrano deployment recipe I've been using for some time to deploy my web app and then restart apache/nginx using the sudo command. Recently cap deploy is hanging when I try to execute these sudo commands. I see the output:
"[sudo] password for "
With my server name and the remote login, but this is not a secure login prompt. The cap shell is just hanging waiting for more output and does not allow me to type my password in to complete the remote sudo command.
Is there a way to fix this or a decent work around? I did not want to remove the sudo password prompt of my remote user for web restart commands.
This seems to happen when connecting to CentOS machines as well. Add the following line in your capistrano deploy file:
default_run_options[:pty] = true
Also make sure to use the sudo helper instead of executing sudo in your run commands directly. For example:
# not
run "sudo chown root:root /etc/my.cnf"
# but
sudo "chown root:root /etc/my.cnf"
The other advice may be sound, but I found that once I updated to Capistrano 2.5.3 the problem went away. I have to make sure I stop running the default versions of tools that came with my O/S.
# prevent sudo prompting for password
set :sudo_prompt, ""