Why do I get “screen is terminating” without root?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
19
down vote

favorite
3












I have installed screen on Fedora 19. When I test the command as root remotely through SSH, it works perfectly. For instance, if I enter screen a new terminal emulator is started and waits for commands. I can detach it, etc. However when I try to do the same once I am logged remotely through SSH as a standard user, the command terminates immediately. The only message I see is [screen is terminating].



Does someone have already had this problem? Is it related to bad permissions?



Update:



$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK) = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
open("/var/run/utmp", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/var/run/screen", st_mode=S_IFDIR) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++


I have tried to change permissions to 777 but then when I execute screen, I get:




Directory '/var/run/screen' must have mode 775.




Therefore, I have reverted my changes.










share|improve this question















migrated from serverfault.com Oct 7 '13 at 8:37


This question came from our site for system and network administrators.














  • What is the command?
    – ewwhite
    Oct 6 '13 at 11:49










  • The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
    – Laurent
    Oct 6 '13 at 15:04










  • Are you on a VPS or hosted server, by chance?
    – ewwhite
    Oct 6 '13 at 15:20










  • It is an hosted server
    – Laurent
    Oct 6 '13 at 15:21










  • strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
    – Emmanuel
    Oct 7 '13 at 16:30















up vote
19
down vote

favorite
3












I have installed screen on Fedora 19. When I test the command as root remotely through SSH, it works perfectly. For instance, if I enter screen a new terminal emulator is started and waits for commands. I can detach it, etc. However when I try to do the same once I am logged remotely through SSH as a standard user, the command terminates immediately. The only message I see is [screen is terminating].



Does someone have already had this problem? Is it related to bad permissions?



Update:



$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK) = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
open("/var/run/utmp", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/var/run/screen", st_mode=S_IFDIR) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++


I have tried to change permissions to 777 but then when I execute screen, I get:




Directory '/var/run/screen' must have mode 775.




Therefore, I have reverted my changes.










share|improve this question















migrated from serverfault.com Oct 7 '13 at 8:37


This question came from our site for system and network administrators.














  • What is the command?
    – ewwhite
    Oct 6 '13 at 11:49










  • The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
    – Laurent
    Oct 6 '13 at 15:04










  • Are you on a VPS or hosted server, by chance?
    – ewwhite
    Oct 6 '13 at 15:20










  • It is an hosted server
    – Laurent
    Oct 6 '13 at 15:21










  • strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
    – Emmanuel
    Oct 7 '13 at 16:30













up vote
19
down vote

favorite
3









up vote
19
down vote

favorite
3






3





I have installed screen on Fedora 19. When I test the command as root remotely through SSH, it works perfectly. For instance, if I enter screen a new terminal emulator is started and waits for commands. I can detach it, etc. However when I try to do the same once I am logged remotely through SSH as a standard user, the command terminates immediately. The only message I see is [screen is terminating].



Does someone have already had this problem? Is it related to bad permissions?



Update:



$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK) = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
open("/var/run/utmp", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/var/run/screen", st_mode=S_IFDIR) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++


I have tried to change permissions to 777 but then when I execute screen, I get:




Directory '/var/run/screen' must have mode 775.




Therefore, I have reverted my changes.










share|improve this question















I have installed screen on Fedora 19. When I test the command as root remotely through SSH, it works perfectly. For instance, if I enter screen a new terminal emulator is started and waits for commands. I can detach it, etc. However when I try to do the same once I am logged remotely through SSH as a standard user, the command terminates immediately. The only message I see is [screen is terminating].



Does someone have already had this problem? Is it related to bad permissions?



Update:



$ strace -e trace=file screen
execve("/usr/bin/screen", ["screen"], [/* 23 vars */]) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libutempter.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpam.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libfreebl3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libaudit.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
access("/home/steam/.nethackrc", F_OK) = -1 ENOENT (No such file or directory)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
open("/var/run/utmp", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/dev/pts/0", st_mode=S_IFCHR) = 0
lstat("/dev/pts/0", st_mode=S_IFCHR) = 0
stat("/var/run/screen", st_mode=S_IFDIR) = 0
Directory '/var/run/screen' must have mode 777.
+++ exited with 1 +++


I have tried to change permissions to 777 but then when I execute screen, I get:




Directory '/var/run/screen' must have mode 775.




Therefore, I have reverted my changes.







permissions gnu-screen






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 27 '17 at 6:40









Ciro Santilli 新疆改造中心 六四事件 法轮功

4,46123938




4,46123938










asked Oct 6 '13 at 9:55









Laurent

2132312




2132312




migrated from serverfault.com Oct 7 '13 at 8:37


This question came from our site for system and network administrators.






migrated from serverfault.com Oct 7 '13 at 8:37


This question came from our site for system and network administrators.













  • What is the command?
    – ewwhite
    Oct 6 '13 at 11:49










  • The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
    – Laurent
    Oct 6 '13 at 15:04










  • Are you on a VPS or hosted server, by chance?
    – ewwhite
    Oct 6 '13 at 15:20










  • It is an hosted server
    – Laurent
    Oct 6 '13 at 15:21










  • strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
    – Emmanuel
    Oct 7 '13 at 16:30

















  • What is the command?
    – ewwhite
    Oct 6 '13 at 11:49










  • The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
    – Laurent
    Oct 6 '13 at 15:04










  • Are you on a VPS or hosted server, by chance?
    – ewwhite
    Oct 6 '13 at 15:20










  • It is an hosted server
    – Laurent
    Oct 6 '13 at 15:21










  • strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
    – Emmanuel
    Oct 7 '13 at 16:30
















What is the command?
– ewwhite
Oct 6 '13 at 11:49




What is the command?
– ewwhite
Oct 6 '13 at 11:49












The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
– Laurent
Oct 6 '13 at 15:04




The simplest one: "screen". I recorded an example at shelr.tv/records/525179c7966080791000005f
– Laurent
Oct 6 '13 at 15:04












Are you on a VPS or hosted server, by chance?
– ewwhite
Oct 6 '13 at 15:20




Are you on a VPS or hosted server, by chance?
– ewwhite
Oct 6 '13 at 15:20












It is an hosted server
– Laurent
Oct 6 '13 at 15:21




It is an hosted server
– Laurent
Oct 6 '13 at 15:21












strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
– Emmanuel
Oct 7 '13 at 16:30





strace -e trace=file screen to check if it fails on file access. Or uses tmuxas a work-around, its works the same except it uses ^b instead of ^a.
– Emmanuel
Oct 7 '13 at 16:30











7 Answers
7






active

oldest

votes

















up vote
4
down vote













The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace.



screen is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.



When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.



screen detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.



So this creates a class of problems that can't be easily debugged with strace.



But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:



  1. Open 2 new terminals

  2. In the first terminal, log in to the remote machine as root

  3. In the second terminal, log in to the remote machine as normal user

  4. Use ps to get the PID of the normal user's shell process in the second terminal

  5. In the first terminal, run strace -f -p SHELLPID

  6. In the second terminal, run screen and watch it fail

  7. In the first terminal, you now have the strace log you need to find out what's really wrong.

The key addition to the strace command is the -f option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p.



I also like to use -ff and specify an output file with -o, as in



strace -ff -o /tmp/screentrace -p SHELLPID


which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace* and the result is usually cleaner than what you get using a single -f.



UPDATE



Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:



chown("/dev/pts/2", 1002, 5) = -1 EPERM (Operation not permitted)


A few lines earlier, it created a pty, which was revealed by TIOCGPTN to be number 2.



open("/dev/ptmx", O_RDWR) = 5
...
ioctl(5, TIOCGPTN, [2]) = 0
stat("/dev/pts/2", st_mode=S_IFCHR) = 0


But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v to the strace options, and looking at the stat after the TIOCGPTN to see who owns the /dev/pts/ entry.






share|improve this answer






















  • Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
    – Laurent
    Oct 14 '13 at 20:36


















up vote
2
down vote













On of possible reasons for that bug - incorrect selinux policies, but according to redhat bugtracker such errors were fixed in fedora 17/18.



As workaround you can change variable SCREENDIR in you ~/.bashrc to something like $HOME/.screen.






share|improve this answer




















  • I have tried but it does not solve the issue.
    – Laurent
    Oct 14 '13 at 20:21

















up vote
0
down vote













When I encountered this error message. I had to adjust my permissions with the following:



chmod 2775 /usr/bin/screen



And this resolved the issue for me. The 2 is very important for the correct access permissions.



You should read up more on SUID, SGID, Sticky Bit, ACL's and how they impact access.






share|improve this answer






















  • u+s works. It's not nice but I can't see other solutions at the moment.
    – anttir
    Jul 24 '15 at 19:14

















up vote
0
down vote













Screen command was already running. So I terminated it and retyped the command.
Yes this is not a pretty good resolution like others but it takes less time to do this.



Just ps and find the pid, kill PID and go ahead with retyping screen command again.



If you are running multiple screen commands, make sure you terminate the correct process associated with your terminal.






share|improve this answer



























    up vote
    0
    down vote













    I found this issue resolved after commenting the following line in /etc/fstab and rebooting:



    devpts /dev/pts devpts defaults 0 0





    share|improve this answer



























      up vote
      0
      down vote













      Ensure no other screen is using that device



      This can be achieved with https://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :



      sudo lsof /dev/ttyS0


      And then kill that process if that is the case.



      For some reason, under this condition, sudo screen can still access the device, but then that connection will miss characters, which are consumed by the other screen.



      Ensure the user has read and write permission to the file



      E.g. on Ubuntu you want to add the user to the dialout group: https://askubuntu.com/a/133244/52975






      share|improve this answer



























        up vote
        0
        down vote













        I got exactly the same issue and a pretty similar strace output.



        This fixed it:



        sudo chmod u+s /usr/bin/screen
        sudo chmod 755 /var/run/screen


        credits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/





        share








        New contributor




        aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.

















          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f93892%2fwhy-do-i-get-screen-is-terminating-without-root%23new-answer', 'question_page');

          );

          Post as a guest






























          7 Answers
          7






          active

          oldest

          votes








          7 Answers
          7






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          4
          down vote













          The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace.



          screen is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.



          When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.



          screen detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.



          So this creates a class of problems that can't be easily debugged with strace.



          But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:



          1. Open 2 new terminals

          2. In the first terminal, log in to the remote machine as root

          3. In the second terminal, log in to the remote machine as normal user

          4. Use ps to get the PID of the normal user's shell process in the second terminal

          5. In the first terminal, run strace -f -p SHELLPID

          6. In the second terminal, run screen and watch it fail

          7. In the first terminal, you now have the strace log you need to find out what's really wrong.

          The key addition to the strace command is the -f option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p.



          I also like to use -ff and specify an output file with -o, as in



          strace -ff -o /tmp/screentrace -p SHELLPID


          which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace* and the result is usually cleaner than what you get using a single -f.



          UPDATE



          Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:



          chown("/dev/pts/2", 1002, 5) = -1 EPERM (Operation not permitted)


          A few lines earlier, it created a pty, which was revealed by TIOCGPTN to be number 2.



          open("/dev/ptmx", O_RDWR) = 5
          ...
          ioctl(5, TIOCGPTN, [2]) = 0
          stat("/dev/pts/2", st_mode=S_IFCHR) = 0


          But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v to the strace options, and looking at the stat after the TIOCGPTN to see who owns the /dev/pts/ entry.






          share|improve this answer






















          • Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
            – Laurent
            Oct 14 '13 at 20:36















          up vote
          4
          down vote













          The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace.



          screen is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.



          When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.



          screen detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.



          So this creates a class of problems that can't be easily debugged with strace.



          But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:



          1. Open 2 new terminals

          2. In the first terminal, log in to the remote machine as root

          3. In the second terminal, log in to the remote machine as normal user

          4. Use ps to get the PID of the normal user's shell process in the second terminal

          5. In the first terminal, run strace -f -p SHELLPID

          6. In the second terminal, run screen and watch it fail

          7. In the first terminal, you now have the strace log you need to find out what's really wrong.

          The key addition to the strace command is the -f option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p.



          I also like to use -ff and specify an output file with -o, as in



          strace -ff -o /tmp/screentrace -p SHELLPID


          which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace* and the result is usually cleaner than what you get using a single -f.



          UPDATE



          Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:



          chown("/dev/pts/2", 1002, 5) = -1 EPERM (Operation not permitted)


          A few lines earlier, it created a pty, which was revealed by TIOCGPTN to be number 2.



          open("/dev/ptmx", O_RDWR) = 5
          ...
          ioctl(5, TIOCGPTN, [2]) = 0
          stat("/dev/pts/2", st_mode=S_IFCHR) = 0


          But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v to the strace options, and looking at the stat after the TIOCGPTN to see who owns the /dev/pts/ entry.






          share|improve this answer






















          • Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
            – Laurent
            Oct 14 '13 at 20:36













          up vote
          4
          down vote










          up vote
          4
          down vote









          The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace.



          screen is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.



          When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.



          screen detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.



          So this creates a class of problems that can't be easily debugged with strace.



          But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:



          1. Open 2 new terminals

          2. In the first terminal, log in to the remote machine as root

          3. In the second terminal, log in to the remote machine as normal user

          4. Use ps to get the PID of the normal user's shell process in the second terminal

          5. In the first terminal, run strace -f -p SHELLPID

          6. In the second terminal, run screen and watch it fail

          7. In the first terminal, you now have the strace log you need to find out what's really wrong.

          The key addition to the strace command is the -f option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p.



          I also like to use -ff and specify an output file with -o, as in



          strace -ff -o /tmp/screentrace -p SHELLPID


          which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace* and the result is usually cleaner than what you get using a single -f.



          UPDATE



          Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:



          chown("/dev/pts/2", 1002, 5) = -1 EPERM (Operation not permitted)


          A few lines earlier, it created a pty, which was revealed by TIOCGPTN to be number 2.



          open("/dev/ptmx", O_RDWR) = 5
          ...
          ioctl(5, TIOCGPTN, [2]) = 0
          stat("/dev/pts/2", st_mode=S_IFCHR) = 0


          But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v to the strace options, and looking at the stat after the TIOCGPTN to see who owns the /dev/pts/ entry.






          share|improve this answer














          The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace.



          screen is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.



          When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.



          screen detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.



          So this creates a class of problems that can't be easily debugged with strace.



          But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:



          1. Open 2 new terminals

          2. In the first terminal, log in to the remote machine as root

          3. In the second terminal, log in to the remote machine as normal user

          4. Use ps to get the PID of the normal user's shell process in the second terminal

          5. In the first terminal, run strace -f -p SHELLPID

          6. In the second terminal, run screen and watch it fail

          7. In the first terminal, you now have the strace log you need to find out what's really wrong.

          The key addition to the strace command is the -f option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p.



          I also like to use -ff and specify an output file with -o, as in



          strace -ff -o /tmp/screentrace -p SHELLPID


          which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace* and the result is usually cleaner than what you get using a single -f.



          UPDATE



          Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:



          chown("/dev/pts/2", 1002, 5) = -1 EPERM (Operation not permitted)


          A few lines earlier, it created a pty, which was revealed by TIOCGPTN to be number 2.



          open("/dev/ptmx", O_RDWR) = 5
          ...
          ioctl(5, TIOCGPTN, [2]) = 0
          stat("/dev/pts/2", st_mode=S_IFCHR) = 0


          But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v to the strace options, and looking at the stat after the TIOCGPTN to see who owns the /dev/pts/ entry.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Oct 14 '13 at 21:08

























          answered Oct 14 '13 at 0:14









          Wumpus Q. Wumbley

          4,1301120




          4,1301120











          • Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
            – Laurent
            Oct 14 '13 at 20:36

















          • Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
            – Laurent
            Oct 14 '13 at 20:36
















          Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
          – Laurent
          Oct 14 '13 at 20:36





          Thank you for the detailed procedure. I have tried to look at the output generated by strace but I cannot figure out what is wrong. Hereafter is the link with the content of the three files generated by strace: pastebin.com/raw.php?i=aeqDwTBX any idea is welcomed :)
          – Laurent
          Oct 14 '13 at 20:36













          up vote
          2
          down vote













          On of possible reasons for that bug - incorrect selinux policies, but according to redhat bugtracker such errors were fixed in fedora 17/18.



          As workaround you can change variable SCREENDIR in you ~/.bashrc to something like $HOME/.screen.






          share|improve this answer




















          • I have tried but it does not solve the issue.
            – Laurent
            Oct 14 '13 at 20:21














          up vote
          2
          down vote













          On of possible reasons for that bug - incorrect selinux policies, but according to redhat bugtracker such errors were fixed in fedora 17/18.



          As workaround you can change variable SCREENDIR in you ~/.bashrc to something like $HOME/.screen.






          share|improve this answer




















          • I have tried but it does not solve the issue.
            – Laurent
            Oct 14 '13 at 20:21












          up vote
          2
          down vote










          up vote
          2
          down vote









          On of possible reasons for that bug - incorrect selinux policies, but according to redhat bugtracker such errors were fixed in fedora 17/18.



          As workaround you can change variable SCREENDIR in you ~/.bashrc to something like $HOME/.screen.






          share|improve this answer












          On of possible reasons for that bug - incorrect selinux policies, but according to redhat bugtracker such errors were fixed in fedora 17/18.



          As workaround you can change variable SCREENDIR in you ~/.bashrc to something like $HOME/.screen.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 13 '13 at 21:10









          Alexander Kudrevatykh

          32817




          32817











          • I have tried but it does not solve the issue.
            – Laurent
            Oct 14 '13 at 20:21
















          • I have tried but it does not solve the issue.
            – Laurent
            Oct 14 '13 at 20:21















          I have tried but it does not solve the issue.
          – Laurent
          Oct 14 '13 at 20:21




          I have tried but it does not solve the issue.
          – Laurent
          Oct 14 '13 at 20:21










          up vote
          0
          down vote













          When I encountered this error message. I had to adjust my permissions with the following:



          chmod 2775 /usr/bin/screen



          And this resolved the issue for me. The 2 is very important for the correct access permissions.



          You should read up more on SUID, SGID, Sticky Bit, ACL's and how they impact access.






          share|improve this answer






















          • u+s works. It's not nice but I can't see other solutions at the moment.
            – anttir
            Jul 24 '15 at 19:14














          up vote
          0
          down vote













          When I encountered this error message. I had to adjust my permissions with the following:



          chmod 2775 /usr/bin/screen



          And this resolved the issue for me. The 2 is very important for the correct access permissions.



          You should read up more on SUID, SGID, Sticky Bit, ACL's and how they impact access.






          share|improve this answer






















          • u+s works. It's not nice but I can't see other solutions at the moment.
            – anttir
            Jul 24 '15 at 19:14












          up vote
          0
          down vote










          up vote
          0
          down vote









          When I encountered this error message. I had to adjust my permissions with the following:



          chmod 2775 /usr/bin/screen



          And this resolved the issue for me. The 2 is very important for the correct access permissions.



          You should read up more on SUID, SGID, Sticky Bit, ACL's and how they impact access.






          share|improve this answer














          When I encountered this error message. I had to adjust my permissions with the following:



          chmod 2775 /usr/bin/screen



          And this resolved the issue for me. The 2 is very important for the correct access permissions.



          You should read up more on SUID, SGID, Sticky Bit, ACL's and how they impact access.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 31 '14 at 3:15

























          answered Dec 31 '14 at 3:09









          Roric

          11




          11











          • u+s works. It's not nice but I can't see other solutions at the moment.
            – anttir
            Jul 24 '15 at 19:14
















          • u+s works. It's not nice but I can't see other solutions at the moment.
            – anttir
            Jul 24 '15 at 19:14















          u+s works. It's not nice but I can't see other solutions at the moment.
          – anttir
          Jul 24 '15 at 19:14




          u+s works. It's not nice but I can't see other solutions at the moment.
          – anttir
          Jul 24 '15 at 19:14










          up vote
          0
          down vote













          Screen command was already running. So I terminated it and retyped the command.
          Yes this is not a pretty good resolution like others but it takes less time to do this.



          Just ps and find the pid, kill PID and go ahead with retyping screen command again.



          If you are running multiple screen commands, make sure you terminate the correct process associated with your terminal.






          share|improve this answer
























            up vote
            0
            down vote













            Screen command was already running. So I terminated it and retyped the command.
            Yes this is not a pretty good resolution like others but it takes less time to do this.



            Just ps and find the pid, kill PID and go ahead with retyping screen command again.



            If you are running multiple screen commands, make sure you terminate the correct process associated with your terminal.






            share|improve this answer






















              up vote
              0
              down vote










              up vote
              0
              down vote









              Screen command was already running. So I terminated it and retyped the command.
              Yes this is not a pretty good resolution like others but it takes less time to do this.



              Just ps and find the pid, kill PID and go ahead with retyping screen command again.



              If you are running multiple screen commands, make sure you terminate the correct process associated with your terminal.






              share|improve this answer












              Screen command was already running. So I terminated it and retyped the command.
              Yes this is not a pretty good resolution like others but it takes less time to do this.



              Just ps and find the pid, kill PID and go ahead with retyping screen command again.



              If you are running multiple screen commands, make sure you terminate the correct process associated with your terminal.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Sep 17 '15 at 4:57









              Shree Harsha

              1




              1




















                  up vote
                  0
                  down vote













                  I found this issue resolved after commenting the following line in /etc/fstab and rebooting:



                  devpts /dev/pts devpts defaults 0 0





                  share|improve this answer
























                    up vote
                    0
                    down vote













                    I found this issue resolved after commenting the following line in /etc/fstab and rebooting:



                    devpts /dev/pts devpts defaults 0 0





                    share|improve this answer






















                      up vote
                      0
                      down vote










                      up vote
                      0
                      down vote









                      I found this issue resolved after commenting the following line in /etc/fstab and rebooting:



                      devpts /dev/pts devpts defaults 0 0





                      share|improve this answer












                      I found this issue resolved after commenting the following line in /etc/fstab and rebooting:



                      devpts /dev/pts devpts defaults 0 0






                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Jan 21 '17 at 22:54









                      Uto Dev

                      11




                      11




















                          up vote
                          0
                          down vote













                          Ensure no other screen is using that device



                          This can be achieved with https://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :



                          sudo lsof /dev/ttyS0


                          And then kill that process if that is the case.



                          For some reason, under this condition, sudo screen can still access the device, but then that connection will miss characters, which are consumed by the other screen.



                          Ensure the user has read and write permission to the file



                          E.g. on Ubuntu you want to add the user to the dialout group: https://askubuntu.com/a/133244/52975






                          share|improve this answer
























                            up vote
                            0
                            down vote













                            Ensure no other screen is using that device



                            This can be achieved with https://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :



                            sudo lsof /dev/ttyS0


                            And then kill that process if that is the case.



                            For some reason, under this condition, sudo screen can still access the device, but then that connection will miss characters, which are consumed by the other screen.



                            Ensure the user has read and write permission to the file



                            E.g. on Ubuntu you want to add the user to the dialout group: https://askubuntu.com/a/133244/52975






                            share|improve this answer






















                              up vote
                              0
                              down vote










                              up vote
                              0
                              down vote









                              Ensure no other screen is using that device



                              This can be achieved with https://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :



                              sudo lsof /dev/ttyS0


                              And then kill that process if that is the case.



                              For some reason, under this condition, sudo screen can still access the device, but then that connection will miss characters, which are consumed by the other screen.



                              Ensure the user has read and write permission to the file



                              E.g. on Ubuntu you want to add the user to the dialout group: https://askubuntu.com/a/133244/52975






                              share|improve this answer












                              Ensure no other screen is using that device



                              This can be achieved with https://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux :



                              sudo lsof /dev/ttyS0


                              And then kill that process if that is the case.



                              For some reason, under this condition, sudo screen can still access the device, but then that connection will miss characters, which are consumed by the other screen.



                              Ensure the user has read and write permission to the file



                              E.g. on Ubuntu you want to add the user to the dialout group: https://askubuntu.com/a/133244/52975







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered May 27 '17 at 6:30









                              Ciro Santilli 新疆改造中心 六四事件 法轮功

                              4,46123938




                              4,46123938




















                                  up vote
                                  0
                                  down vote













                                  I got exactly the same issue and a pretty similar strace output.



                                  This fixed it:



                                  sudo chmod u+s /usr/bin/screen
                                  sudo chmod 755 /var/run/screen


                                  credits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/





                                  share








                                  New contributor




                                  aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                  Check out our Code of Conduct.





















                                    up vote
                                    0
                                    down vote













                                    I got exactly the same issue and a pretty similar strace output.



                                    This fixed it:



                                    sudo chmod u+s /usr/bin/screen
                                    sudo chmod 755 /var/run/screen


                                    credits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/





                                    share








                                    New contributor




                                    aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                    Check out our Code of Conduct.



















                                      up vote
                                      0
                                      down vote










                                      up vote
                                      0
                                      down vote









                                      I got exactly the same issue and a pretty similar strace output.



                                      This fixed it:



                                      sudo chmod u+s /usr/bin/screen
                                      sudo chmod 755 /var/run/screen


                                      credits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/





                                      share








                                      New contributor




                                      aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.









                                      I got exactly the same issue and a pretty similar strace output.



                                      This fixed it:



                                      sudo chmod u+s /usr/bin/screen
                                      sudo chmod 755 /var/run/screen


                                      credits: https://www.linuxquestions.org/questions/linux-newbie-8/screen-terminates-immediately-4175444530/






                                      share








                                      New contributor




                                      aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.








                                      share


                                      share






                                      New contributor




                                      aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.









                                      answered 5 mins ago









                                      aguaviva

                                      1011




                                      1011




                                      New contributor




                                      aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.





                                      New contributor





                                      aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.






                                      aguaviva is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                      Check out our Code of Conduct.



























                                           

                                          draft saved


                                          draft discarded















































                                           


                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function ()
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f93892%2fwhy-do-i-get-screen-is-terminating-without-root%23new-answer', 'question_page');

                                          );

                                          Post as a guest













































































                                          Popular posts from this blog

                                          How to check contact read email or not when send email to Individual?

                                          Displaying single band from multi-band raster using QGIS

                                          How many registers does an x86_64 CPU actually have?