I've got this question answered here bash - running remote script from local machine about how could I use remote command with sudo involved. I thought it was working, because I got message that my server was successfully restarting etc so I chose answer. But today I saw that server actually was not restarting, but being killed for some reason.
Things I did, when I ran this command first time:
ssh user#host.com -t 'sudo /etc/init.d/script restart' #or -t just after ssh, same thing
I got this message:
Restarting openerp-server: Stopping openerp-server: openerp-server.
Starting openerp-server: openerp-server.
Connection to host.com closed.
So yeah, then I thought everything was good. But actually going to see if process restarted I saw it was not working.
And when I tried to restart again (with same command), I got this message:
Restarting openerp-server: Stopping openerp-server: start-stop-daemon: warning: failed to kill 25205: No such process
openerp-server.
Starting openerp-server: openerp-server.
Connection to host.com closed.
But if I use same command when directly connected to remote server, everything works fine and my script restarts server normally.
Same command I mean this:
ssh user#host.com
sudo /etc/init.d/script restart
So what the heck is going on here?
It seems likely that the script that starts it up is doing something naughty that relies on the TTY staying alive briefly after the command returns. It is probably the immediate exit that is causing trouble. If it starts a background job that's attached to the shell inside the TTY, and detaches shortly afterwards, then closing the connection might kill the shell and kill the job inside it. That would explain why, when you restart, the script thinks there's a process number for the service, but then can't find it: maybe the process number gets logged somewhere, but then the process gets killed off before it can get going.
To confirm, you might try a couple of things. Log in remotely, run your sudo command, then exit immediately:
ssh user#host.com
sudo /etc/init.d/script restart; exit
and see if this immediate exit also hits the same problem.
Also try
ssh user#host.com -t 'sudo /etc/init.d/script restart; sleep 30'
to force it to wait for a bit, and see if that gets you anywhere.
Related
I'm trying to execute the command:
ssh nvidia#ubuntu-ip-address "/opt/ads2/arm-linux64/bin/ads2 svcd&"
This works so far except that it hangs in the remote terminal when "/opt/ads2/arm-linux64/bin/ads2 svcd&" is executed, unless i enter ctrl+c. So I'm looking for a command that, after executing the command, exits from the remote terminal and continue executing the local bash script.
thanks in advance
When you run a command in background on a terminal, regardless of weather it be local or remotely, if you attempt to logout most systems will warn you have running jobs. One further attempt to logout and your jobs get killed as you exit.
In order to avoid this you need to detach your running jobs from terminal.
if job is already running you can
disown -h <jobspec ar reported by jobs>
If you want to run something in background and then exit leaving it running you can use nohup
nohup command &
This is certainly ok on init systems ... not sure if it works exactly like this on systems that use systemd.
On many of my servers autofs is hung and a process is trying to access a mount, and while I ssh to the remote host the it hangs there until I press Crtl+C from my keyboard
dew:~ # ssh dew00922
but when I press Crtl+C its goes to the prompt
dew:~ # ssh dew00922
^C-bash-3.2#
-bash-3.2#
I'm trying to send trap signal via the ssh but that also hangs
dew:~ # ssh dew00922 'trap 2 && service autofs restart'
Any help in fixing this issue.
When you ssh in, it's trying to run /etc/profile and then ~root/.profile (or ~root/.bash_profile or ~root/.bash_login) and ~root/.bashrc. One of those scripts runs a command that is trying to access a hung filesystem. When you press ^ C, you're killing the script and getting a prompt from the bash on dew0922. At that point you are logged into dew00922 and can run commands. Any commands you run that try to access a hung filesystem will hang.
timeout is the tool made for such problems:
ssh dew00922 'timeout 2 service autofs restart'
See man timeout for more information
I would like to make a shutdown-script for my raspberry pi to shut down anothe raspberry pi over ssh.
The script works if it is running itself but at the shutdown routine the ssh command is not executed.
So that I have done until now:
Made the script in /etc/init.d:
#!/bin/sh
# the first thing is to test if the shutdown script is working
echo "bla bla bla " | sudo tee -a /test.txt
ssh pi#10.0.0.98 sudo shutdown -h now
Made it executable
sudo chmod +x /etc/init.d/raspi.sh
Made a symlink to the rc0.d
sudo ln -s /etc/init.d/raspi.sh /etc/rc0.d/S01raspi.sh
Now I know so far that the shutdown script is working outside of the shutdown routing by calling itself and the shutdown symlink I made is also working partially because I see the changes in the test.txt file every time I shut down.
Can anyone help me how to solve my problem?
Have you tried with single quotes?
The first link in Google has it
http://malcontentcomics.com/systemsboy/2006/07/send-remote-commands-via-ssh.html
What about the sudo, how do you solve entering the password?
https://superuser.com/questions/117870/ssh-execute-sudo-command
Please check this or other links on the web that have useful information.
I would have send all this in a comment but I cant yet because of reputation.
I have now got the script running by myself. I do not really know why it is now working but I write it down beneath and maybe someone else can clearifiy it.
I don´t think the first two changes at my system makes a difference but I also write it down. In the meanwhile because I do not managed the script to get working I had made a button to shutdown the system manually. Also I made a script which backs the mysql-database up (which is on the Raspberry Pi which I would like to switch off with the script) and copies the backup to the raspberry pi which should switch of the other raspberry automatically via the shutdown-script. This happens with scp and also for the password is a key generated.
I have also changed my script to get a log-message out of the script.
#!/bin/sh
ssh -t -t pi#10.0.0.99 'sudo shutdown -h now' >> /home/osmc/shutdown.log 2>&1
To get it into the shutdown-routine I used:
sudo update-rc.d raspi-b stop 01 0
I hope somebody can say me why my code now worked on the first day but not on the next few days until now.
I structured a command to suspend or shutdown a remote host over ssh. You may find this useful. 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ā)
EDIT this is fixed. See my answer below.
I have a headless server running transmission-daemon on Angstrom Linux. I am able to SSH into the machine and invoke transmission-daemon via this init script; however, the process terminates as soon as I log out.
The command issued in the script is:
start-stop-daemon --chuid transmission --start --pidfile /var/run/transmission-daemon.pid --make-pidfile --exec /usr/local/bin/transmission-daemon --background -- -f
After starting the daemon via # /etc/init.d/transmission-daemon start, I can verify using ps that the process is owned by the user transmission (which is not the user I am logging in as via SSH).
I've tried every variation of the above command that I am aware of, including:
With and without the --background option for start-stop-daemon
Appending > /dev/null 2>&1 & to the start-stop-daemon command (source -- although there seems to be mixed results in that thread as to whether this is the right approach)
Appending > /dev/null 2>&1 & </dev/null & (source)
Adding & to the end of the command
Using nohup
None of these seems to work -- the result is always the same: the process exits immediately after I close the SSH session.
What can/should I do to keep the daemon running after I disconnect the SSH session?
Have you tried using GNU Screen?
It allows you to keep your session open even if you disconnect (but not if you exit).
It's a simple case of:
apt-get install screen
or
yum install screen
Since I cannot leave comments yet :), here is a good site that explains some functions of Screen, http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/
I use screens all the time, to do exactly what you are talking about. You open a screen, in the terminal, do what you need to do, then you can log off and your process will still be running.
sudo loginctl enable-linger your_user
# This allows users who are not logged in to run long-running
# service after ssh session ends
This is now resolved. Here's the background: at some point prior to running into this problem, something happened to my $PATH (I don't recall what) and the location where transmission-daemon lived (/sbin) was removed. Under the mistaken impression that transmission-daemon was no longer present on the system, I installed again from an ipk. This is the state the system was in when I initially asked this question.
I don't know why it made a difference, but once I corrected my $PATH and started running transmission-daemon installed at /sbin, everything worked again. The daemon keeps running after I log out.
I'm connecting to my ubuntu server using ssh. I start an encoding program using a command. However, it seems that when my ssh session closes (because I started it on a laptop which went to sleep). Is there a way to avoid this (of course preventing my laptop from sleeping is not a permanent solution).
Run your command with nohup or use screen
nohup is better when your program generate some loging output because it's forward to file and then you can check it, but with screen you can detach ssh session and when you log again you can restore your work-space. For encoding I'll use nohup. It is easier and you probably run it in background, so you really don't need detaching
Screen is the best for you.
screen -S some_name
than run it. Detach it with: ctrl+a d
Next time, attach it with:
screen -rd some_name
You can have more runnning screens. To show the list of them:
screen -ls
Install "screen" on your ubuntu server, that way you can start any program in your session, disconnect the output of the program from your current session and exit.
Later when you connect again to your server, you can restore the program which will continue running and see its progress.