I'm trying to invoke a program to run on startup in /etc/rc.local which runs two commands:

  1. Start a detatched screen using screen -dmS name
  2. Send a command to that screen using screen -S name -X stuff command

However the command relies on environmental variablesbeing set. I've set these EXPORT commands in both the root .profile and the root .pam_environment file. For reference they are:

export PATH=$PATH:/usr/local/cuda-7.0/bin

export LD_LIBRARY_PATH=:/usr/local/cuda-7.0/lib64

However the started screen cannot see these variables and errors out with error while loading shared libraries: libcudart.so.7.0: cannot open shared object file: No such file or directory - which is what I'd expect if these variables weren't set.

The trouble is I can't figure out why they're not set. My best guess is that, for some reason, the screen is using /bin/sh (which is what it reports if I echo $0, whereas the root's default shell is /bin/bash

The weirder thing is that this only happens for a screen instantiated like this at boot. If I use the same command to start a detached screen it all works correctly (and uses /bin/bash) with no problems with environmental variables.

Any idea what is causing this and how to fix? I'm using Ubuntu 14.04 LTS.

1 Answer 1


Maybe your $SHELL is not set or set to /bin/sh? Or you have a shell set to /bin/sh in your .screenrc file?

See screen's documentation:

-s program

sets the default shell to the program specified, instead of the value in the environment variable $SHELL (or /bin/sh if not defined). This can also be defined through the shell .screenrc command. See also there.

And there:

shell command

Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL. This is useful if you'd like to run a tty-enhancer which is expecting to execute the program specified in $SHELL. If the command begins with a - character, the shell will be started as a login-shell. Typical shells do only minimal initialization when not started as a login-shell. E.g. Bash will not read your ~/.bashrc unless it is a login-shell.

i.e. adding the following line to .screenrc in your home folder should set the default shell of screen to bash

shell /bin/bash
  • Thanks, adding the -s flag to strictly force /bin/bash did the trick. However this is still confusing as the value for $SHELL is set as /bin/bash and running screen from a terminal starts it as /bin/bash also. It's only in this one scenario that screen starts in /bin/sh/ and I'm still unsure why. Jan 19, 2016 at 10:29
  • Maybe it starts too early at boot when $SHELL is not yet populated?
    – choroba
    Jan 4, 2019 at 13:57
  • maybe it's a user preference vs system preference. since the "system" is not really root, is it? Apr 13, 2019 at 19:20
  • 1
    I experienced the same problem when running screen inside a docker container. $SHELL was set to /bin/bash and I had a .screenrc with the line shell $SHELL but still new screen sessions were using /bin/sh. In the end explicitly setting shell /bin/bash in my .screenrc meant that screen started with bash and so did new screen sessions.
    – anthls
    Dec 11, 2019 at 1:37

You must log in to answer this question.

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