I'm pretty sure nothing will happen by posting this, but it's not like I should just leave it ...
That error is still well alive despite the numerous reports.
The package version 4.4.0-6 (GNU version 4.04.00; the current one at the time of posting this), designated for Zesty, installed just fine on 16.04 LTS through a DEB file from official repo but provided absolutely nothing related to this issue by how easy it still is to replicate: as §root§ (doing this as an user with §sudo su§ permissions not tested), §su§ into another user and try to run §screen§, doesn't matter which parameters used as long as the parameter doesn't make §screen§ just reply without executing anything. As §root§ no problems, obviously.
I remember well, on either 12.04 LTS or 14.04 LTS, that I managed to get a version of §screen§ where this and the §chmod 777§ problem with §/var/run/screen/§ were fixed by no longer using §/var/run/screen/§, but some subfolder under §~/.screen/§, disregarding the fact the executing user was, usually, logged into by §root§.
Don't ask me to help fix this by writing C[++], I can't even write a Hello World program, although I can often interpret what the existing line does.
lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Hi Jouni,
thank you for your report and your help to make Ubuntu better.
I rejected the suggestion that nothing happens and instead tried to reproduce to understand the issue better :-)
# I have used screen with and without -q, just with -q it is more readable and needs less returns
# works as my own user
$ screen
# becoming root via sudo, then screen still works
$ sudo su -
$ screen
# from there become another user, still works
$ su otheruser -
$ screen
I have no local root login atm, so for reproduction might I ask how you get your initial shell?
Do you have a remote login with root login allowed or is this a local root logon?
As fallback I created a local KVM Guest, and enabled root login there:
$uvt-kvm create --memory 2048 --cpu 4 --disk 8 --password=ubuntu zesty-test-screen release=zesty arch=amd64 label=daily
# there I then enabled root login in /etc/sshd_config
$ ssh root@kvmguest
$ su ubuntu
$ screen
Here I was then able to reproduce your case.
"Cannot open your terminal '/dev/pts/0' - please check."
And it makes sense as the current local /dev/pts/0 is owned by root.
As a workaround there you can e.g. run
$ script /dev/null
# This will create a /dev/pts/* of your user that screen can reuse, not a fix but a workaround
I've found that some directly wrap this up as
$ /usr/bin/script -q -c "/usr/bin/screen ${*}" /dev/null
So overall, working with a main root login should never be the default for security reasons.
If you do so you might end up with some extra hickups and IMHO that is one of them.
You can create a case of this issue without root login, by switching around users with su.
But the root cause always is that the current user can't access /dev/pty/* due to being different user than the initial terminal creating one.
Since there is a workaround for it available and easily to be found on the internet (now one more with this bug) I think it is not a high severity.
Also I don't think screen should create a different pty for his own user on its own.
I'd more consider this (not to allocate a new tty a feature/limitation) of su.
That said I'd rate this as wishlist issue or almost a Won't Fix - but I'd leave it open to you or others to comment if this is more severe than I think.