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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.