How to activate screen with user enviornment?

Have you tried using bash --rcfile “Path to your bashrc” -c “commands”

My rc.local has

shopt -s expand_aliases
source ~/.bashrc

You may want to try the full path to your .bashrc

Thanks, I’ll try on next reboot, but I think it reads it.

I’ve never actually done it either, but I just made a quick attempt at it and I think I have it working. This is what I did.

$ sudo semanage fcontext -a -t bin_t '/usr/bin/screen'
$ sudo restorecon -v /usr/bin/screen
$ sudo mkdir /etc/systemd/system/getty@tty7.service.d
$ sudo tee /etc/systemd/system/getty@tty7.service.d/override.conf << 'END'
Description=Screen on %I

ExecStart=-/usr/bin/screen -S %I -U
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now getty@tty7.service

Then press Ctrl+Alt+F7 to switch to VT7 and hopefully find your running screen instance there. Note that it is running as root and it is unlocked. The next thing you would surely want to look into would be locking the screen session down somehow (e.g. using screen’s lockscreen command in the /root/.screenrc file).

Edit: I was too quick to say I had it working. SELinux is blocking everything because it is still running as getty_t. I’m not sure how to get it to switch to unconfined_t, but you would need to do that before this will work.

Edit: It looks like it was easier that I thought it would be. I just needed to add a SELinuxContext=... line to the override.conf file. I’ve revised the above example and I think it is working now.

The next thing to do is passwd root to set root’s password if you have not already and then make sure the following line is in /root/.screenrc.


It should then start the screen session locked and you will have to enter the root account’s password to unlock it.

(Use C-a x to re-lock the terminal.)

You might want to add the following line to your ~/.screenrc to prevent accidentally detaching screen from your virtual terminal if you actually use your VT (it replaces the detach hotkey with the lock command).

bind d lockscreen

(You may also want to override ^d if you ever use that.)

I think maybe the clue is in manual. So using -m switch ignores $STY environment. But not sure how else to create new screen and detached it.

-m causes screen to ignore the $STY environment variable. With screen -m creation of a new session is enforced, regardless whether screen is called from within another screen session or not. This
flag has a special meaning in connection with the `-d’ option:

Thanks @glb
If I understand this, I need to be on actual console? I use my F37 boxes in server environment, so I’m not on the location. Also does it need to run selinux?

You don’t need to be on the actual console, but screen will reserve one and be available if you want to access it that way. It also doesn’t require selinux. So if you have that disabled or in permissive mode (unadvised!), then you can skip those steps. If you want to attach to it remotely, you should be able to with the usual screen -r tty7 and then detaching with C-a d should leave it running. If you need to restart the service for whatever reason, that could be done with systemctl restart getty@tty7.service (beware that this will kill all running processes in the existing screen session).

P.S. This would just be cosmetic, but if you want to be able to refer to the service as screen@tty7.service, you could add the following to the bottom of that override.conf file.


Apologies if I’m misunderstanding or not explaining well.

This is how I did this today without using a user service:
The service file goes into /etc/systemd/system/ I used screen.service as the name:

Description=Screen Service

User="insert your username here"
ExecStart=/bin/bash -c "/usr/bin/screen -d -m -S d bash"


Enable the service and reboot.

This is what the environment Looks like for me when run this way

TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:li#24:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:ti=\E[?1049h:te=\E[?1049l:Km=\E[M:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:
LESSOPEN=||/usr/bin/ %s

I was also able to achieve the same results with:

Description=Screen Service with script

ExecStart=/bin/bash -c "/home/grumpey/bin/screen.bash" 


screen.bash was:

/bin/bash -c "/usr/bin/screen -d -m -S top bash -c top"
/bin/bash -c "/usr/bin/screen -d -m -S bash bash"

Thanks for an update
1.) Remainonexit shows me as

Unknown key name ‘Remainonexit’ in section ‘Service’, ignoring.

so I’ve used RemainAfterExit not sure if they were the same.
2.) screen starts normally, but when creating new screen window, it’s again without bash environment. Have you tried to create new window (CTRL a- c)? when entering the screen?

Thanks @glb . This is actually working :slight_smile: Wow. This will ease up after reboots hassle on all servers . I presume that screen name can be changed and you defined it with %I in ExecStart?

Remainonexit was a typo. Thanks!

I had not. When I do, it has the same environment as the old window.

Out of curiosity does any of this change if you set bash as a login shell in ~/.screenrc
defshell -/bin/bash

Yeah, %I is just a placeholder for whatever is after the @ symbol in the service filename (getty@tty7.service) so if you ran, for example, cp -r /etc/systemd/system/getty@tty7.service.d /etc/systemd/system/getty@tty8.service.d then you would get another auto-starting screen session on tty8 and the session name would be “tty8” because of the %I substitution. But you can use whatever you want in place of the %I. You don’t have to name the screen sessions after the virtual terminal they are running on.

1 Like

Yes it did change and environment is now present. I actually put it in /etc/screenrc as I started service as root. I assume it would load bash environment now regardless how I start it

Good call. It makes sense to make these screen sessions login shells, so I added that - to the SHELL=... line in my earlier example as well so that adding defshell -/bin/bash to /etc/screenrc should no longer be necessary for anyone who might find and use that example.

1 Like

Thanks for the update @glb . What does - do when adding to the path? I’ve never seen it used before.

It causes your ~/.bash_profile script to be called instead of ~/.bashrc.

Excerpted from man bash:

A login shell is one whose first character of argument zero is a -, or one started with the --login option.

An interactive shell is one started without non-option arguments (unless -s is specified) and without the -c option, whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state.

The following paragraphs describe how bash executes its startup files. If any of the files exist but cannot be read, bash reports an error. Tildes are expanded in filenames as described below under Tilde Expansion in the EXPANSION section.

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.