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.
Related
I want to run "screen" on a debian linode server, starting up over a ssh terminal window. I'd like a shell script to start and detach a screen, so that a process can continue when I log off. I'd also like the logging file screenlog.0 to be produced, so that there's a record if the process crashes.
But there's a problem in getting the log file to write. Locally, on a mac terminal window,
% screen -dm -L sh -c 'echo hello'
works fine, "hello" gets written to screenlog.0. But the same command issued in a ssh window to the server executes, but nothing gets written.
However, if in that window I go into screen,
% screen -L
and then do some stuff, the activity is written to screenlog.0 (on the server).
What am I missing?
It turns out that the screen() command can have problems. The above command sends no output to screenlog.0 under 'Debian GNU/Linux 9 (stretch)' , while 'Ubuntu 14.04.1 LTS' writes the odd message, "error: could not start server! try running as root!", to screenlog.0, even when running as root. 'Linux Mint 18.1' and MacOSX run correctly.
I was advised to use the venerable unix command "nohup" to solve my problem of detaching a process and logging its output, even when you close the ssh connection. Ordinarily, when you close a terminal window, the signal SIGHUP is sent to any processes that were started there. But
% nohup myprog > logfile.txt &
works perfectly. Old way, good way.
I mindlessly use nohup ssh for issuing a remote ssh command without worrying about the accident hangup. Now I'm starting to think about it and it is not pretty clear.
What I'm wondering is that why just doing "ssh remote sleep 100 &" stops the job after few seconds? For instance,
$ ssh remote sleep 100 &
[1] 13358
$
[1]+ Stopped ssh remote sleep 100
By what reason is this job stopped? Could you explain the internals of this job control?
If you want the remote command to keep working until it's finished (and not depend on the ssh connection with the remote host): you could use screen (or tmux) .
connect using ssh to the remote host
once connected: screen to start a screen session (a kind of "virtual terminal", that will keep running until you close it, instead of depending on your own connection to it)
you can then detach from screen (ctrl-a d) and re-attach to it later (from another machine, etc) : just ssh again, "screen -l" to list screens, and "screen -r" to re-attach to one. Read about screen on the net.
The reason your job is stopped is not linked to the command, but to the internal of job handling. Some (good) infos can be found on http://www.linusakesson.net/programming/tty/ (search for background if you don't read the whole thing. But read the whole thing ^^). In a nutshell ... writing to a TTY from a background job will cause a SIGTTOU to suspend the entire process group (maybe your ssh asked for a password? or it displays something when connecting?)
The advantage of screen over running on the remote host usign "nohup" are numerous. The main one is that if you try to re-connect to a nohup program (ex: vi) it can't (easily) be done... especially if it is multi-line. But when you re-attach to a screen session, you see the (virtual) terminal as if you never left it (ie, it's updated if the command added things on the screen, and it still have rows/columns, etc).
You can also work at several person on the same terminal (or have some person "view it" while one works in it).
Etc.
The command
ssh remote sleep 100 &
only runs ssh in the background. Once ssh is started on the local machine, control returns to the local shell, regardless of what is running (via sshd) on the remote end.
I've searched, googled, sat in IRC for a week and even talked to a friend who is devoutly aligned with linux but I haven't yet received a solid answer.
I have written a shell script that runs as soon as I log into my non-root user and runs basically just does "./myprogram &" without quotation. When I exit shh my program times out and I am unable to connect to it until I log back in. How can I keep my program running after I exit SSH of my non-root user?
I am curious if this has to be done on the program level or what? My apologizes if this does not belong here, I am not sure where it goes to be perfectly honest.
Beside using nohup, you can run your program in terminal multiplexer like screen or tmux. With them, you can reattach to sessions, which is for example quite helpful if you need to run terminal-based interactive programs or long time running scripts over a unstable ssh connections.
boybu is a nice enhancement of screen.
Try nohup: http://linux.die.net/man/1/nohup
Likely your program receives a SIGHUP signal when you exit your ssh session.
There's two signals that can cause your program to die after your ssh session ends: SIGHUP and SIGPIPE.
SIGHUP will be sent to your program because the parent process (ssh) has died. You can get around this either by using the program nohup (i.e. nohup ./myprogram &) or by using the shell builtin disown (./myprogram& disown)
SIGPIPE will be sent to your program if it tries to write to stdout or stderr after the ssh session has been disconnected. To get around this, redirect them to a file or /dev/null, i.e. nohup ./myprogram >/dev/null 2>/dev/null &
You might also want to use the batch (or at) command, in addition to the other answers (nohup, screen, ...). And ssh has a -f option which might interest you.
I'm trying to start a test server via ssh but it always dies once i disconnect from ssh.
Is there a way to start a process (run the server) so it doesn't die upon the end of my ssh session?
As an alternative to nohup, you could run your remote application inside a terminal multiplexor, such as GNU screen or tmux.
Using these tools makes it easy to reconnect to a session from another host, which means that you can kick a long build or download off before you leave work and check on its status when you get home. For instance. I find this particularly useful when doing development work on servers that are very remote (in a different country) with unreliable connectivity between me and them, if the connection drops, I can simply reconnect and carry on without losing any state.
If you're SSHing to a Linux distro that has systemd, you can use systemd-run to launch a process in the background (in systemd's terms, "a transient service"). For example, assuming you want to ping something in the background:
systemd-run --unit=pinger ping 10.8.178.3
The benefit you'll get with systemd over just running a process with nohup is that systemd will track the process and its children, keep logs, remember the exit code and allow you to cleanly kill the process and all its children. Examples:
See the status and the last lines of output:
systemctl status pinger
Stream the output:
journalctl -xfu pinger
Kill:
systemctl kill pinger
Yes; you can use the nohup command to swallow the HUP ("hangup") signal that is sent to your program when you hang up your SSH session.
Alternatively, if you're writing the server yourself, you can code it to register a handler for the HUP signal, and swallow it inside the program (rather than using an external nohup program that does the same).
In addition to the other replies, you could start your test server thru batch (or at) but as Brian answered you should call daemon
And you could pass the -f option to ssh
As an alternative to nohup, screen, et al. you could revise your server to invoke daemon to detach it from the terminal. This is the idiomatic way to write services for linux.
See also daemon(3).
Somehow this isn't yielded by a google search.
I'm scripting a server in node.js. I start the server by executing its script with the node program:
node myserver.js
But the server staying up is dependent on my ssh session. How can I make this (and all such processes) persistent? Init.d?
Use the nohup command:
From http://en.wikipedia.org/wiki/Nohup
nohup is a POSIX command to ignore the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. The HUP (hangup) signal is by convention the way a terminal warns depending processes of logout.
Try this:
nohup node myserver.js &
Have you tried GNU screen? Using it, a process can continue to run when you end your ssh session. nohup is a standard *nix command that will allow you to do the same, albeit in a more limited way.
Use screen. Type screen from the terminal and then launch your process. If you disconnect you can reconnect to the ssh session, by typing 'screen -ls' (to see active screens) and 'screen -r' to reconnect.
The program needs to run in a daemonized mode. Here's a good post for doing this in Ubuntu.
nohup is good to run the job under. If the job is already running, you can try disown -h (at least in bash)