0

I've seen people saying use screen.

But when I typed "screen" in the terminal, I got: "Please set a terminal type."

Any idea how I can fix this?

Vlastimil Burián
  • 27,586
  • 56
  • 179
  • 309
henryforever14
  • 103
  • 1
  • What does `echo $TERM` say on the remote box shell? – yaegashi Sep 10 '15 at 02:03
  • @yaegashi it says "dumb". I want to run bash. How do I set this variable? – henryforever14 Sep 10 '15 at 02:08
  • You can set the variable with `TERM=` as with any other variable, but the real issue here is why it is not getting set automatically according to your terminal type. What type of terminal are you using? – Celada Sep 10 '15 at 02:13
  • @Celada What do you mean by type of terminal? The remote box runs linux. I am not sure about the distribution though. The shell seems to be bash. – henryforever14 Sep 10 '15 at 02:50
  • I mean your *local* terminal. SSH clients are supposed to forward along the terminal type to the SSH server when connecting, so if it's set wrong in the remote SSH session that's most likely because it's set wrong in your local terminal. – Celada Sep 10 '15 at 03:22
  • 1
    What's your local environment and terminal software you are using? It might be gnome-terminal if you are on Linux desktop, or Putty on Windows. Besides that, setting `TERM` to `xterm` or `linux` or `vt100` would probably make `screen` runnable temporarily. – yaegashi Sep 10 '15 at 03:29
  • @Celada,yaegshi, I am running terminal from OS X. Any idea how I can solve this issue permanently? – henryforever14 Sep 10 '15 at 12:15
  • @henryforever14 If you are using the regular `Terminal.app` from MacOS then your `$TERM` setting should be reasonable by default, definitely not `dumb`. Check your `$TERM` setting on the local terminal. That will tell you whether it's a problem with SSH not carrying it over to the remote system or whether it's wrong on the local system in the first place. – Celada Sep 10 '15 at 12:30
  • @Celada Yes. I am using Terminal.app. Locally, $TERM says xterm-256color. – henryforever14 Sep 10 '15 at 15:40
  • I have no idea why the `$TERM` value is not carrying over to the session on the SSH server, that's weird. But as a workaround you can set `$TERM` to the same, `xterm-256color`, instead of `dumb`, and then you will be able to run `screen`. – Celada Sep 10 '15 at 16:32

2 Answers2

3

To answer your initial question, the most basic way to keep a command running after logging out is to run it with the nohup command.

For example, if I wanted to run a script, and drop it into the background while keeping it running after logging out I would type:

nohup ./myscript &

More information can be found here: https://en.wikipedia.org/wiki/Nohup

Otherwise, as you stated, screen is a good option.

nyxgeek
  • 483
  • 2
  • 9
  • Depending on what you want, it may be better to use setsid for this: `setsid ./myscript /dev/null 2>&1`. That's a bit more similar to what a real daemon process will do. (Tweak the redirections as desired if, for instance, you want to catch output in a logfile.) – Tom Hunt Sep 10 '15 at 15:11
  • Thanks for information on Nohup. But unfortunately, I don't have root access to the remote box and it seems that nohup is not available, i.e., I get "bash: nohup: command not found". – henryforever14 Sep 10 '15 at 15:43
0

SOLUTION 1 :

If you want to run screen , these are the way :
Login to your user :
-- To create a new session for screen
screen -S screenname
-- To detach from the screen 
Ctl + ad
-- To reconnect to screen :
screen -dr screenname
-- To check the current open screens :
screen -ls
-- While in screen , you can use 
   Ctl + ac (to create new screenwindows)
   Ctl + an (move to next screenwindow)
   Ctl + ap (move to previous screenwindow)

SOLUTION 2 :

You can run a script like this :
/fullpath/to/script/scriptname.sh >> /fullpath/to/log/logname.log 2>&1 
Ctl + z
bg %1 (run in background)
disown %1   
-- To check if its running :
ps -ef | grep scriptname.sh

Note : Ctl here means control key

soumyaranjan
  • 1,044
  • 7
  • 5