I want to start screen and put a couple of programs running inside on startup. I've seen many similar posts but none answered my question. so I put in rc.local following 2 lines:

  screen -dmS scr bash -c 'ytop; exec bash'
  screen -S scr -X screen 1 bash -c 'nvtop; exec bash'

which works fine, but when I enter this screen, once logged in to the server, and want to create new screen, it doesn't have environment variables in it. How can I start it in the way that would have all root's envars?
new window looks like this:


$PATH in window is

Yet in the rc.local created windows $PATH (/usr/bin:/bin) is the same, but the prompt is normal, so it looks that it reads /etc/profile
Window initialized by rc.local has normal prompt:

[root@mysrv ~]#

PATH is also a bit more than fresh window, but not same as if I start screen manually from the terminal as root

echo $PATH

When I start screen by myself it's normal prompt.

[root@mysrv ~]#


echo $PATH

Interestingly if I exit ytop it shows me proper prompt. Only when creating new screen somehow looses this envars.
I tried also running:

su - root -c `screen -dmS scr bash -c 'ytop; exec bash'`

but I get the same result.

2 Answers 2


I think your problem here is the session-handling of bash. Bash - like any other shell interpreter - detects if it is started in the backgroud, or if it is attached to a terminal ( Interactive / Non-interactive mode ). Background is found here. My guess is, that your problems are solved by providing the -l switch to the first bash command:

screen -dmS scr bash --login -c 'ytop; exec bash'

The --login switch makes bash read all startup files, like /etc/profile, ~/.bash_profile, ~/.bash_login, and ~/.profile - which should contain the environmental variables you are missing.

  • Thanks @Martin, but it didn't work when ran from rc.local. Maybe I would need to specify user, but didn't find it manual how to. But interesting really is i I quit ytop in screen one it shows me normal bash prompt (so obviously it read /etc/profile, ~/ .bash_profile files. When I enter and attache screen and create new screen then it suddenly looses all those variables.
    – DenisZ
    May 31, 2021 at 13:51
  • Hmm... okay, that is weird. The --login option doesn't have user credentials; it changes only the way bash is run. (use su - <login> to start a process as a different user). If the problem is only with the second screen command, why don't you create a second session like this: screen -dmS scr2 bash -c 'nvtop; exec bash'
    – Martin
    May 31, 2021 at 14:02
  • I tried putting into rc.local su - root -c screen -dmS scr bash -c 'ytop; exec bash', but same result, maybe are the quotes. What I do normally is always have several screens within one screen session open on each server, so I'd like to create a few starting screens automatically every time server is rebooted. Then I login go to screen and add new screens. I want them all under one session, so it's easier to manage.
    – DenisZ
    May 31, 2021 at 16:57
  • the rc.local is executed as root, so su - root does not change anything.
    – Martin
    May 31, 2021 at 17:14
  • I checked $PATH and it is /usr/bin:/bin, whereas if I start screen manually is /usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin, so also any programs that I start without this path would start. still interesting is windows that I start within rc.local have good PS (prompt) but as mentioned starting new one doesn't carry over $PS variable from /etc/profile
    – DenisZ
    Jun 1, 2021 at 16:19

I finally found a solution. It's very simple. I had to edit file /etc/screenrc and add following line

defshell -/bin/bash

And than it works normally when starting screen in detached mode (screen -dmS scr bash -c 'ytop; exec bash'), and also when later entering this screen and creating new window, bash environment will be present.

bellow solution also didn't work.

So to start screen with normal shell and variables you have to do it >with init, so :

su - root -c screen -dmS scr bash -c 'ytop; exec init'

So this will have normal environment like if you manually start screen >and detach it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .