If a do screen in linux, and then ssh into some other machine, run a job there, detach from screen and disconnect the terminal. If i open the terminal again i can go that session and job is still running. I just want to know how internally this screen is working?
Detach does exactly what literally means.
It detaches the screen process from it's parent.
It means that his parent (your ssh session) will not inform his dependent/child process about its termination.
For more info this links could be useful:
https://en.wikipedia.org/wiki/Nohup
https://unix.stackexchange.com/questions/3886/difference-between-nohup-disown-and
After ssh and successful login use screen -S screen_name to generate screen, then new tab will open. Run your program and you may close it. To see your program running use: screen -r screen_name.
Related
Does anyone know any way of doing this? The help would be greatly appreciated, I've been beating my head over this one for a while now, and I can't seem to find any way to get scripts to auto-start and display in the foreground as they would if I had manually started them.
what i want to do is basically just power on the vm, let it boot, then watch the script run and echo results to the console or whatever the script would normally display if ran manually
I've been able to use Cron and systemd to run the script I would like to run at startup, but I cannot figure out any way to get these scripts to run in the screen, as they would if I had typed ./startup_script.sh
i am currently testing everything in a headless Debian 11 vm. Auto login as root is already enabled. i just need to complete this last step but i don't know how to do.
You can fire up a tmux session and send keys it to start a script like this:
tsid="session_name"
my_script="/home/script.sh"
# create new tmux session
tmux new-session -d -s ${tsid}
# launch the script in the tmux session
echo "launching script in a tmux session called ${tsid}"
tmux send-keys -t ${tsid} "${$my_script}" 'C-m'
I do something similar to start a "quad-pane" to my raspberry pi devices. I can send commands to each pane via ssh without looking at the screen I am sending commands to. I can send commands to the panes from any ssh session without actually connecting to a gui, or being in the "session". This way, another machine can have that session up on a monitoring display and I can momentarily ssh over a command to the host and it will show over there without ever actually connecting to the window. The panes can run scripts and and have the output on the each respective screen/pane waiting for me to connect later and look at it. Every now and then I'll pull up my quad feed to see what's happening... then disconnect and leave it all running.
# function to send an arbitrary command to a tmux pane
# arg1: full id of pane, e.g. "pi4-host01:quad-feed.0"
# arg2+ command(s) to send to pane
tmux_send_command_to_pane_id() {
local tpid cmd
tpid="${1:-0}"
cmd="${#}"
echo "cmd to send to pane: ${tpid}: ${cmd}"
tmux send-keys -t "${tpid}" "${cmd}" 'C-m'
}
If you pair something like this with cron or systemd, i'd imagine you could get to your goal relatively quick. It does depend on installing tmux. I know others use screen, but I have become a fan of tmux for whatever reason.
A nice answer on systemd scripts here -> https://unix.stackexchange.com/a/47715/376937
Here is another question that may help as well:
Tmux command to run shell command on active pane?
I am trying to re-attach different screen sessions that I have open. As usual, I try:
screen -r [screen name]
This normally works, but now it keeps hanging the terminal. Ctrl+c doesn't help, and I end up having to close the terminal. Other screen functions (screen -ls, screen -S [new screen name]) work fine.
One of the screens has a process running in it. I can see from the existence of generated output files that the process is still running. I just can't access the screen itself.
I tried creating a new screen, detaching it, and re-attaching it - this works fine. I can access new screens, but not the ones that were open before this problem popped up.
You should do kill the screens which has problem. Try,
screen -X -S <screenname> kill
If it's not working, you should kill these processes by yourself. First you should find which are those have an issue. By typing;
ps aux
Then find PID number of process which you want to kill. And type;
kill -9 <pidnumber>
And check it works fine :)
Regards,
Evren
I have a DOSEMU process running on Linux (Mint 11). The process modify data over the network, and I'm afraid that if a user close the program using the [X] button of the window instead of properly shutdown the program, then the shared data can be corrupted.
In Windows, I can use NoClose to disable the [X] close button. Is there any way to do it in Linux?
Use -t switch to run DOSEMU not in a window but inside your console. There is no need to run it from X at all - you can just switch to a text-mode console (Ctrl-Alt-1...6) and run dosemu -t from there, your users will never notice it.
You could also run
sudo nohup dosemu -t your_command
and close your console safely - it would result in DOSEMU execute your_command in the background in case you don't need to do manual input
In short:
What is the most elegant solution to keep a perl/python/R/etc script/program running on a server (connected via ssh) when the remote server connection is closed (shell-window closed)?
In detail:
I have written some scripts that will run several days on our server. However, after connecting to the server via SSH over a linux-shell, starting the program and closing the window will also kill the program - OK, thats not new. But, how must the Server be configured to keep the program running after the ssh-connection is closed?
"screen" can be one solution, hmm but for me that to much typing and sometime I forgot to start a screen session and start the program
Thanks for your advice!
Cheers,
Yeti
NOHUP - http://en.wikipedia.org/wiki/Nohup
ssh your_server
nohup nice perl your_script &
exit
if you see the man page of ssh you can find an example below the "-n" option.
ssh -n <user>#<server> <cmd> &
In the hope that someone else might find this question and find this information useful, there is an application called "screen" out there that can also let you achieve this.
Most distributions should have them in their repositories under the screen package name. If I wanted to make a screen, I would simply run screen -dmS screenName command and it would run the command in a different "screen", which can be accessed with screen -r screenName. You can detach from a screen at any time using CTRL+A+D.
I hope someone can benefit from this information, as it is useful when you'd like to run a process but also be able to review its output assuming it has any (which many of my applications do).
I've got a program running in a GNOME Terminal, but the screensaver is acting up and won't let me back in with my password. While waiting for a fix for the gnome-screensaver bug, is there some way to see the output (or even take over the process) in a virtual console (Ctrl-Alt-F1) without being able to interact with the GNOME Terminal?
Clarification: The original issue was the screensaver, but the question I'd like answered is how to see the output from a process running in another terminal, after starting the process without any logging to file. I'm guessing it should be possible to set the output device of a process from a different shell? Or is it possible to put a process in another shell into background mode, and get it into the foreground in the current shell? Or even ask GNOME Terminal to redirect or copy the output?
I've had luck in the past killing the screensaver from a virtual console, unlocking X session.
# Get the pid (xscreensaver, gnome-screensaver, etc.)
ps -f -u $(whoami) | grep screensaver
kill -9 12345 # Replace 12345 with the real pid
EDIT: Seems like this has been thought of, and you should use one of these commands, depending on which screensaver program you use:
xscreensaver-command -exit
gnome-screensaver-comand --exit
See the man page for those commands for more details.
Usual way is to pipe the output to a file, like program > program.log
Do tail -f program.log in another tab of Gnome console, and the same in the non-X console.
Alternatively, use tee to duplicate the output in the same console: program | tee program.log
ssh in to the box. kill the screensaver. su to become root and kill -9 if it's really acting up.
Usually Gnome-Terminal displays the output of one vty out of /dev. So just connect your console to that vty.
Launch program with screen.
Open another terminal, launch screen -x and you have two terminals acting like one. Try it, it's fun :)