Debian Bug report logs - #644788
screen 4.1.0 can't attach to a running or detached screen 4.0.3 session

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: screen 4.1.0 can't attach to a running or detached screen 4.0.3 session

Date: Sun, 09 Oct 2011 04:52:42 +0200

Package: screen
Version: 4.1.0~20110819git450e8f3-1
Severity: important

If I have a detached screen 4.0.3-14 running, upgrade screen to version
4.1.0~20110819git450e8f3-1 and then try to reattach to the running
detached screen with the new version, the "screen -r" process hangs
until I kill it with "kill -TERM" and I seem to have no chance to
reattach to the running screen except to downgrade screen again to
4.0.3-14 and then call "screen -r" again.

This can be a problem for people who are used to run remote
dist-upgrades inside screen if the ssh connection is interrupted.

See the following addresses for discussions of this issue:

https://lists.gnu.org/archive/html/screen-devel/2011-10/msg00002.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641867#47

I currently suspect this commit to be the culprit:

http://git.savannah.gnu.org/cgit/screen.git/commit/?id=e3fc19a176c1ed2c266aca03cb5bcc17d0192630

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (900, 'testing'), (600, 'stable'), (400, 'oldstable'), (110, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-rc7-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages screen depends on:
ii  dpkg          1.16.1        
ii  install-info  4.13a.dfsg.1-8
ii  libc6         2.13-21       
ii  libncursesw5  5.9-2         
ii  libpam0g      1.1.3-4       
ii  libtinfo5     5.9-2         

screen recommends no packages.

Versions of packages screen suggests:
ii  byobu    4.37-1 
ii  iselect  1.4.0-1

-- no debconf information

Message #12 received at 644788@bugs.debian.org (full text, mbox, reply):

From: "Barak A. Pearlmutter" <barak@cs.nuim.ie>

To: 644788@bugs.debian.org

Subject: one possible solution

Date: Tue, 11 Oct 2011 10:48:44 +0100

Before proceeding with an upgrade, the kernel package checks if the
running kernel will be removed, and if so asks the user to confirm,
with a default of aborting the upgrade.

I would suggest a similar strategy here: check if a screen process is
running using the old incompatible executable, and if so inform the
user and ask for confirmation, with a default of aborting the upgrade.

Such a strategy would allow uploading into unstable rather than
experimental despite this "screen 4.1.0 can't attach to a running or
detached screen 4.0.3 session" issue.

					--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/

Message #17 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: "Barak A. Pearlmutter" <barak@cs.nuim.ie>, 644788@bugs.debian.org

Subject: Re: Bug#644788: one possible solution

Date: Tue, 11 Oct 2011 16:20:11 +0200

Hi Barak,

Barak A. Pearlmutter wrote:
> Before proceeding with an upgrade, the kernel package checks if the
> running kernel will be removed, and if so asks the user to confirm,
> with a default of aborting the upgrade.
> 
> I would suggest a similar strategy here: check if a screen process is
> running using the old incompatible executable, and if so inform the
> user and ask for confirmation, with a default of aborting the upgrade.
> 
> Such a strategy would allow uploading into unstable rather than
> experimental despite this "screen 4.1.0 can't attach to a running or
> detached screen 4.0.3 session" issue.

Thanks for writing down elaborately what was lingering in my mind just
as "screen -ls && exit 1" so far!

What you described is probably the way to go if this issue is not a
bug but expected by upstream. I though yet haven't got any response
about this issue from upstream, so I'll wait a little bit more before
going into any direction.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #22 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@deuxchevaux.org>

To: screen-devel@gnu.org

Cc: 644788@bugs.debian.org

Subject: Re: [screen-devel] Current screen HEAD can't reattach to a detached screen 4.0.3

Date: Fri, 18 Nov 2011 19:11:40 +0100

Hi Sadrul,

On Fri, Nov 18, 2011 at 12:47:59PM -0500, Sadrul Habib Chowdhury wrote:
> 2011/10/8 Axel Beckert <abe@deuxchevaux.org>:
> > I'm currently preparing an upload of the current screen HEAD to Debian
> > (either Unstable or Experimental, not yet decided) and I noticed that,
> > if I have a screen 4.0.3 (as currently in Debian Stable/Unstable) is
> > running, I can't reattach to that with the new screen 4.1.0 snapshot,
> > it just hangs until I kill it with "kill -TERM" as Ctrl-C does not
> > help.
> >
> > As for me the common way to dist-upgrade Debian or Ubuntu boxes
> > (especially remote servers) is to run the whole process inside a
> > screen, this is a quite critical issue. So I wonder:
> >
> > Is this issue known? Not circumventable? An unexpected bug? Anyone has
> > an idea where this comes from? Or does it not happen at all with vanilla
> > screen versions?
> 
> Hi! Sorry for the late reply. :-(

Better late than never. So thanks for replying! :-)

> This is a know and expected issue. The way the screen 'server' and the
> screen 'client'/'display' communicate has changed slightly, and so a
> newer (4.1.0) screen 'client'/'display' won't be able to communicate
> with an older (4.0.3) screen 'server' process. Unfortunately, there
> isn't a workaround for this.

That's what I feared. :-(

There's no chance for a command line option (something like e.g.
--legacy-server) to let the client communicate with a 4.0.3 server?
That would probably help a lot for the migration.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Message #27 received at 644788@bugs.debian.org (full text, mbox, reply):

From: richo <richo@psych0tik.net>

To: Screen development <screen-devel@gnu.org>

Cc: 644788@bugs.debian.org

Subject: Re: [screen-devel] Current screen HEAD can't reattach to a detached screen 4.0.3

Date: Sat, 19 Nov 2011 14:27:50 +1100

[Message part 1 (text/plain, inline)]

On 18/11/11 19:11 +0100, Axel Beckert wrote:
>Hi Sadrul,
>
>On Fri, Nov 18, 2011 at 12:47:59PM -0500, Sadrul Habib Chowdhury wrote:
>> 2011/10/8 Axel Beckert <abe@deuxchevaux.org>:
>> > I'm currently preparing an upload of the current screen HEAD to Debian
>> > (either Unstable or Experimental, not yet decided) and I noticed that,
>> > if I have a screen 4.0.3 (as currently in Debian Stable/Unstable) is
>> > running, I can't reattach to that with the new screen 4.1.0 snapshot,
>> > it just hangs until I kill it with "kill -TERM" as Ctrl-C does not
>> > help.
>> >
>> > As for me the common way to dist-upgrade Debian or Ubuntu boxes
>> > (especially remote servers) is to run the whole process inside a
>> > screen, this is a quite critical issue. So I wonder:
>> >
>> > Is this issue known? Not circumventable? An unexpected bug? Anyone has
>> > an idea where this comes from? Or does it not happen at all with vanilla
>> > screen versions?
>>
>> Hi! Sorry for the late reply. :-(
>
>Better late than never. So thanks for replying! :-)
>
>> This is a know and expected issue. The way the screen 'server' and the
>> screen 'client'/'display' communicate has changed slightly, and so a
>> newer (4.1.0) screen 'client'/'display' won't be able to communicate
>> with an older (4.0.3) screen 'server' process. Unfortunately, there
>> isn't a workaround for this.
>
>That's what I feared. :-(
>
>There's no chance for a command line option (something like e.g.
>--legacy-server) to let the client communicate with a 4.0.3 server?
>That would probably help a lot for the migration.
>
>		Kind regards, Axel

What about the obvious, just keep a 4.03 binary around while you do the
upgrade.

If you have to disconnect, reattach to the screen session with 4.0.3, and if
it all goes well, nuke that session and begin using 4.1

Cheers

richo

--
richo || Today's excuse:

Your Pentium has a heating problem - try cooling it with ice cold
water.(Do not turn off your computer, you do not want to cool down the
Pentium Chip while he isn't working, do you?)
http://blog.psych0tik.net

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@deuxchevaux.org>

To: screen-devel@gnu.org

Cc: 644788@bugs.debian.org

Subject: Re: [screen-devel] Current screen HEAD can't reattach to a detached screen 4.0.3

Date: Sat, 19 Nov 2011 09:26:05 +0100

Hi,

On Sat, Nov 19, 2011 at 02:27:50PM +1100, richo wrote:
> What about the obvious, just keep a 4.03 binary around while you do the
> upgrade.

Well, the thing with it is that it's not that obvious. So thanks for
the idea! :-)

The 4.0.3 and 4.1.0 debian packages can't be installed at the same
time as of now. I'll think about how I can implement this. It's not
trivial, but doable.

Grub did something similar for the grub1 to grub2 update. And I can
check if screen sessions are running and do a normal upgrade if not.

The other idea I had was to refuse the upgrade as long as a screen is
running in a way that all packages except screen are upgraded until
the screen session is closed.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Message #37 received at 644788@bugs.debian.org (full text, mbox, reply):

From: richo <richo@psych0tik.net>

To: Screen development <screen-devel@gnu.org>

Cc: 644788@bugs.debian.org

Subject: Re: [screen-devel] Current screen HEAD can't reattach to a detached screen 4.0.3

Date: Sun, 20 Nov 2011 01:27:01 +1100

[Message part 1 (text/plain, inline)]

On 19/11/11 09:26 +0100, Axel Beckert wrote:
>Hi,
>
>On Sat, Nov 19, 2011 at 02:27:50PM +1100, richo wrote:
>> What about the obvious, just keep a 4.03 binary around while you do the
>> upgrade.
>
>Well, the thing with it is that it's not that obvious. So thanks for
>the idea! :-)
>
>The 4.0.3 and 4.1.0 debian packages can't be installed at the same
>time as of now. I'll think about how I can implement this. It's not
>trivial, but doable.
>
>Grub did something similar for the grub1 to grub2 update. And I can
>check if screen sessions are running and do a normal upgrade if not.
>
>The other idea I had was to refuse the upgrade as long as a screen is
>running in a way that all packages except screen are upgraded until
>the screen session is closed.
>
>		Kind regards, Axel
>

I would literally just keep a copy of the binary. Don't worry about trying to
keep both versions installed ala gentoo slots, I think you'll just make more
headaches for yourself.

you could be very sneaky and do something like

for i in `dpkg -L screen`; do
    mkdir -p `dirname $i`
    cp $i /tmp/screen_backup/$i
done

to make a backup of everything that the screen package installs in case it
all goes really pearshaped.

Let me know how you go. I've switched to tmux now (ironically, doing the
screen upgrade in tmux would also work pretty well..) but I may do a trial
upgrade of screen just out of curiosity.

Cheers

richo
--
richo || Today's excuse:

Jan  9 16:41:27 huber su: 'su root' succeeded for .... on /dev/pts/1
http://blog.psych0tik.net

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Screen development <screen-devel@gnu.org>

Cc: 644788@bugs.debian.org

Subject: Re: [screen-devel] Current screen HEAD can't reattach to a detached screen 4.0.3

Date: Sat, 19 Nov 2011 17:57:11 +0100

Hi,

richo wrote:
> I would literally just keep a copy of the binary.

If the binary alone suffices...

> Don't worry about trying to keep both versions installed ala gentoo
> slots, I think you'll just make more headaches for yourself.

I don't think that's worth it either.

> you could be very sneaky and do something like
>
> for i in `dpkg -L screen`; do
>     mkdir -p `dirname $i`
>     cp $i /tmp/screen_backup/$i
> done

Hrm. That looks quite ugly and not very clean to me. But this or a
variant with not all files are a possible option, yes.

> to make a backup of everything that the screen package installs in case it
> all goes really pearshaped.

My current favourite though is something like

  screen -ls && exit 1

or

  ps aux | grep -q SCREEN && exit 1

or both in the preinst or preconfigure script of the package plus a
warning that screen can be just upgraded if no more screen is running.
That way dpkg would do most of the work for me.

If there are no Conflicts with other packages, IMHO the best way would
be to do the whole dist-upgrade in screen except screen itself (it
would refuse to do so) and after everything else is through and fine,
exit the screen session to finally upgrade screen itself.

> Let me know how you go. I've switched to tmux now (ironically, doing the
> screen upgrade in tmux would also work pretty well..)

That was my very first thought and is also a possible alternative to
be mentioned in the Debian Wheezy release notes. A less laudable one
for screen, though.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #47 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Justin B Rye <jbr@edlug.org.uk>, 649240@bugs.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Sat, 19 Nov 2011 11:56:25 -0800

[Message part 1 (text/plain, inline)]

On Sat, Nov 19, 2011 at 05:24:34PM +0000, Justin B Rye wrote:
> > Axel Beckert wrote:
> >> Possible suggestions for the release notes: Use tmux instead of screen
> >> for the dist-upgrade. Not really a laudable note for screen, but I
> >> have currently no better idea.

> Would it make sense to recommend putting screen on hold and upgrading
> it separately after the dist-upgrade is finished?  That wouldn't work
> for something like udev or gdm3, but it sounds like the simplest
> strategy for a "leaf" package like screen.

> (We'll need material for the release notes eventually, but first
> screen 4.1.0 is obviously going to need to put some warnings and
> recommendations in a NEWS.Debian file.)

Any such mitigation strategies will be a poor substitute for having screen
actually work properly across upgrades.  There is nowhere that we can put
such a recommendation that we can ensure users will see it before they start
the upgrade; and once they've started the upgrade inside of a screen
session, it's too late to put the package on hold / start the upgrade
outside of screen / do anything at all except hope you don't have to
reattach to the screen to answer the debconf/conffile prompts and complete
the upgrade.

Given that in other quarters I'm consistently hearing that screen has
stagnated and been overtaken by tmux, it's incredibly bad form for the new
upstream version to have broken protocol compatibility like this.  I think
the screen maintainer should insist on upstream fixing protocol
compatibility before allowing this version into unstable.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #52 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Steve Langasek <vorlon@debian.org>, 644788@bugs.debian.org

Cc: Justin B Rye <jbr@edlug.org.uk>, 649240@bugs.debian.org

Subject: Re: Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Sat, 19 Nov 2011 22:34:15 +0100

Hi,

Steve Langasek wrote:
> On Sat, Nov 19, 2011 at 05:24:34PM +0000, Justin B Rye wrote:
> > > Axel Beckert wrote:
> > >> Possible suggestions for the release notes: Use tmux instead of screen
> > >> for the dist-upgrade. Not really a laudable note for screen, but I
> > >> have currently no better idea.
> 
> > Would it make sense to recommend putting screen on hold

IMHO no. Most people won't read those recommendations. Besides I've
never read such a recommendation before, neither for udev nor for
gdm3. And I do read the release notes since approximately the
Sarge/Etch dist-upgrade.

> > and upgrading it separately after the dist-upgrade is finished?

That's my current plan, but caused by a preconfigure or preinst script
which fails if active screen sessions are running like udev did if it
wasn't upgraded together with the kernel once.

> > (We'll need material for the release notes eventually, but first
> > screen 4.1.0 is obviously going to need to put some warnings and
> > recommendations in a NEWS.Debian file.)

Ehm, Justin, you seem not aware that there is already a "first" 4.1.0
package in Experimental which does exactly that:

http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html

(Look for the string "NEWS".)

The reason why I uploaded it to experimental and not to unstable is
exactly the one we're now discussion about. :-)

> Any such mitigation strategies will be a poor substitute for having screen
> actually work properly across upgrades.

Agreed.

> There is nowhere that we can put such a recommendation that we can
> ensure users will see it before they start the upgrade;

Agreed.

> and once they've started the upgrade inside of a screen session,
> it's too late

I disagree.

> to put the package on hold

Yes, it's to late for that, but not for that:

> start the upgrade outside of screen / do anything at all except hope
> you don't have to reattach to the screen to answer the
> debconf/conffile prompts and complete the upgrade.

Nope. It should do the trick if the 4.1.0 package fails to install
very early in a way so that dpkg makes a rollback if the maintainer
script encounters running screen sessions and then advises the user to
wait with the screen upgrade until that session is finished.

That's the way I currently plan to go.

> Given that in other quarters I'm consistently hearing that screen has
> stagnated and been overtaken by tmux,

Well, it has stagnated if you take the average of several years, but
it has taken up (a little) speed in the last two years with fresh
blood in the team as it seems.

I also disagree that it has been overtaken by tmux:

I found tmux not really usable. That's why I took care of the slightly
weathered screen package. But I know this opinion isn't the majority
of people who tell things about screen and tmux. E.g. IMHO tmux'
documentation doesn't help a lot. I wasn't able to implement something
I did for screen in 10 minutes with tmux in 2 hours (and then I mostly
gave up).

> it's incredibly bad form for the new upstream version to have broken
> protocol compatibility like this.

I agree.

> I think the screen maintainer should insist on upstream fixing
> protocol compatibility before allowing this version into unstable.

I'd be happy if you could write that on screen-devel. Best would be to
reply to group-reply to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788#22

I'm happy about everyone who helps to persuade upstream to fix that
issue properly. :-)

P.S.: I didn't get Justin's mail (yet).

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #57 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Justin B Rye <jbr@edlug.org.uk>

To: 644788@bugs.debian.org

Cc: Axel Beckert <abe@debian.org>

Subject: Bug#644788: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Sat, 19 Nov 2011 23:07:12 +0000

I should mention that I've got involved in this conversation because
this issue was raised as a bugreport for the release-notes package,
and thus copied to debian-doc:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649240
http://lists.debian.org/debian-doc/2011/11/msg00004.html

Axel Beckert wrote:
> Steve Langasek wrote:
>> Justin B Rye wrote:
>>> Would it make sense to recommend putting screen on hold
> 
> IMHO no. Most people won't read those recommendations.

Well, the people who don't read the warnings aren't relevant to the
question of what warnings should be given.  Of course if a solution is
found that won't inconvenience people doing dist-upgrades, debian-doc
can forget it.

> Besides I've
> never read such a recommendation before, neither for udev nor for
> gdm3. And I do read the release notes since approximately the
> Sarge/Etch dist-upgrade.

I imagine the reason nobody recommended putting udev on hold is that
it wouldn't have worked - too many things depend on it.  For screen,
things are different.
 
>>> and upgrading it separately after the dist-upgrade is finished?
> 
> That's my current plan, but caused by a preconfigure or preinst script
> which fails if active screen sessions are running like udev did if it
> wasn't upgraded together with the kernel once.

That can help block people from charging blindly into a situation
where they've got lost screen sessions, but won't it be at the cost of
derailing a multi-package install with a sudden dpkg error message?
If people were warned to upgrade screen as a separate process they
could avoid either problem.

>>> (We'll need material for the release notes eventually, but first
>>> screen 4.1.0 is obviously going to need to put some warnings and
>>> recommendations in a NEWS.Debian file.)
> 
> Ehm, Justin, you seem not aware that there is already a "first" 4.1.0
> package in Experimental which does exactly that:
> 
> http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html
> 
> (Look for the string "NEWS".)

Hurrah for NEWS.Debian and apt-listchanges!
 
> The reason why I uploaded it to experimental and not to unstable is
> exactly the one we're now discussion about. :-)

It doesn't actually offer a solution yet, though, does it?  My point
was that once there's a consensus it'll go there before it needs to go
in the release notes.
-- 
JBR   A long time ago this practice was followed, especially in the
      upper classes, but today even the children of the lower classes
      perform no executions, and this is extreme negligence.
                              - "Hagakure", Yamamoto Tsunetomo (1716)

Message #62 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Justin B Rye <jbr@edlug.org.uk>

Cc: 644788@bugs.debian.org, 649240@bugs.debian.org

Subject: Re: Bug#644788: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Sun, 20 Nov 2011 02:13:00 +0100

Hi Justin,

Justin B Rye wrote:
> I should mention that I've got involved in this conversation because
> this issue was raised as a bugreport for the release-notes package,
> and thus copied to debian-doc:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649240
> http://lists.debian.org/debian-doc/2011/11/msg00004.html

Ah right, debian-doc is the owner of the release-notes package, not
debian-release (to which I'm subscribed). Thanks for the
clarification!

> Axel Beckert wrote:
> > Steve Langasek wrote:
> >> Justin B Rye wrote:
> >>> Would it make sense to recommend putting screen on hold
> > 
> > IMHO no. Most people won't read those recommendations.
> 
> Well, the people who don't read the warnings aren't relevant to the
> question of what warnings should be given.  Of course if a solution is
> found that won't inconvenience people doing dist-upgrades,

I currently don't see any straight forward solution that does not
inconvenient those who want to do the dist-upgrade inside screen --
if upstream doesn't provide a solution.

> debian-doc can forget it.

Can forget what?

> I imagine the reason nobody recommended putting udev on hold is that
> it wouldn't have worked - too many things depend on it.  For screen,
> things are different.

Ok. Putting screen on hold is just what the following would enforce
with more drastic measures. I guess the best variant would be to use
both.

> >>> and upgrading it separately after the dist-upgrade is finished?
> > 
> > That's my current plan, but caused by a preconfigure or preinst script
> > which fails if active screen sessions are running like udev did if it
> > wasn't upgraded together with the kernel once.
> 
> That can help block people from charging blindly into a situation
> where they've got lost screen sessions,

Exactly that's what it's for and unless there's a solution from
upstream, I think, it's inevitable. (Ok, there are other ideas like
renaming the binary package to something like screen410, but IMHO this
would pull in tons of other problems...)

> but won't it be at the cost of derailing a multi-package install
> with a sudden dpkg error message?

From my experiences this works fine if a package with very few reverse
dependencies fails, but can cause big headaches if a package with many
reverse dependencies fail.

According to apt-rdepends -r, screen only has the following reverse
dependencies:

screen
  Reverse Depends: apt-dater (0.8.6-1)
  Reverse Depends: byobu (4.37-1)
  Reverse Depends: cereal (0.24-1)
  Reverse Depends: epoptes-client (0.3.1-1)
  Reverse Depends: mdm (0.1.3-2)
  Reverse Depends: podracer (1.4-1.1)
  Reverse Depends: screenie (1.30.0-6)

(More than I expected though, I just knew of byobu and screenie.)

> If people were warned to upgrade screen as a separate process they
> could avoid either problem.

Or at least make the experience less sudden and unexpected.

> >>> (We'll need material for the release notes eventually, but first
> >>> screen 4.1.0 is obviously going to need to put some warnings and
> >>> recommendations in a NEWS.Debian file.)
> > 
> > Ehm, Justin, you seem not aware that there is already a "first" 4.1.0
> > package in Experimental which does exactly that:
> > 
> > http://packages.qa.debian.org/s/screen/news/20111009T025041Z.html
> > 
> > (Look for the string "NEWS".)
> 
> Hurrah for NEWS.Debian and apt-listchanges!

I even got replies on the screen-devel ML due to this entry. Actually
such a mail revived that thread so I got that statement from upstream.
:-)

> > The reason why I uploaded it to experimental and not to unstable is
> > exactly the one we're now discussion about. :-)
> 
> It doesn't actually offer a solution yet, though, does it?

Nope, because I wanted to wait for a statement from upstream, but
didn't want to hold back fixes for approx. 30 to 40 bugs. :-) This
statement came yesterday, but wasn't what I hoped for, so I pulled the
release team in.

> My point was that once there's a consensus it'll go there before it
> needs to go in the release notes.

Exactly. My mail to the release team was merely informational that
there's an issue which very likely will need an entry in the release
notes, but not what should be written there yet.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #67 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Axel Beckert <abe@debian.org>, 649240@bugs.debian.org

Cc: 644788@bugs.debian.org, Justin B Rye <jbr@edlug.org.uk>, screen-devel@gnu.org

Subject: Re: Bug#649240: Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Sat, 26 Nov 2011 14:54:38 -0600

[Message part 1 (text/plain, inline)]

On Sat, Nov 19, 2011 at 10:34:15PM +0100, Axel Beckert wrote:
> > and once they've started the upgrade inside of a screen session,
> > it's too late

> I disagree.

> > to put the package on hold

> Yes, it's to late for that, but not for that:

> > start the upgrade outside of screen / do anything at all except hope
> > you don't have to reattach to the screen to answer the
> > debconf/conffile prompts and complete the upgrade.

> Nope. It should do the trick if the 4.1.0 package fails to install
> very early in a way so that dpkg makes a rollback if the maintainer
> script encounters running screen sessions and then advises the user to
> wait with the screen upgrade until that session is finished.

> That's the way I currently plan to go.

Doing this as part of a dist-upgrade between releases does not make for a
very usable experience, because the upgrade will be at an arbitrary point in
the upgrade when the screen preinst script is run, which may cause apt to
abort with the system in a state that a subsequent 'apt-get dist-upgrade'
run is not sufficient to correctly upgrade from.

> > it's incredibly bad form for the new upstream version to have broken
> > protocol compatibility like this.

> I agree.

> > I think the screen maintainer should insist on upstream fixing
> > protocol compatibility before allowing this version into unstable.

> I'd be happy if you could write that on screen-devel. Best would be to
> reply to group-reply to
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644788#22

> I'm happy about everyone who helps to persuade upstream to fix that
> issue properly. :-)

Well, done. :)

Screen maintainers, could you please correct this lack of compatibility with
the old protocol, which causes problems for any users trying to do
distribution upgrades from inside of screen?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #72 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 649240@bugs.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Fri, 2 Dec 2011 23:29:05 +0100

Hi Steve,

Steve Langasek wrote:
> Screen maintainers, could you please correct this lack of
> compatibility with the old protocol, which causes problems for any
> users trying to do distribution upgrades from inside of screen?

JFTR:

I just checked if reverting a few patches would help us in an easy
way, but the changes seem to be too invasive.

Sadrul bumped the msg struct version deliberately in these commits:

http://git.savannah.gnu.org/cgit/screen.git/commit/?id=8b46d8a5d214ab124db868a47c5e569f1e83c33e
http://git.savannah.gnu.org/cgit/screen.git/commit/?id=e3fc19a176c1ed2c266aca03cb5bcc17d0192630

From the commit message of the last one:

    A small change in the messaging system is necessary, thus bumping
    the message version, for the first time since it has been
    introduced, it seems. But I don't think it's going to break
    anything.

Well, I guess we have a different opinion WRT to the breakage caused
by this commit. ;-)

For the discussion, the commit message refers to
https://savannah.gnu.org/bugs/?24029

Explanation of the message versions used so far in screen at
http://git.savannah.gnu.org/cgit/screen.git/tree/src/screen.h#n179

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #77 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 03:18:34 +0100

Hi Yaroslav,

Yaroslav Halchenko wrote:
> pardon my blunt question:

No, this question is completely valid and understandable and came up
already in the two mentioned bug reports (#644788 and #649240).

> but is there really possibility to have them 'fixed'?

Well, there are several ways to "fix" this, some are surely less
perfect and less favourable solutions, but then again -- as you
correctly state -- the perfect ones may not be possible.

But we have to choose at least one solution because otherwise the
dist-upgrade to Wheezy will be very ugly (and therefor not
debian-like) for those who run it inside a screen session remotely and
the network connections dies after screen has been dist-upgraded. (So
IMHO there is no option to do nothing at all. ;-)

> I am reading upstream response just as a statement that it can't be
> achieved due to a chance in protocol...

Yep.

I see the following options:

A) Add an option to screen so the screen client speaks the old
   protocol to the running server protocol. This IMHO would be best
   solution and one without a big impact. It's also something which
   could be Debian-only, i.e. a patch. (It of course would be better
   if upstream could be convinced to add such an option. :-)

B) Take care that nobody upgrades the screen package while running
   inside a screen without being aware of the possible problems. There
   are few ideas how to implement this:

   1) Mention it in the release notes that screen has to be upgraded
      to the very end of the dist-upgrade process if the dist-upgrade
      is running inside screen.

      Disadvantage: Many admins don't read the release notes.

   2) Fail in the preinst maintainer script if screen server processes
      are running like udev did from Etch to Lenny if not upgraded
      together with the kernel.

      Disadvantage: According to Steve Langasek this could be very
      ugly, so I suggest to inform via debconf about the issue and let
      the user decide if he wants to continue, abort (or maybe get a
      shell to connect to that screen session and close it)

   3) Tell people via the release notes that they should not run the
      dist-upgrade inside screen, but inside tmux instead.

      Disadvantage: Many admins don't read the release notes. People
      may still distrust tmux for such an crucial task or just may not
      be comfortable with the parts where tmux's behaviour differs
      from screen's behaviour.

C) Provide both, screen 4.0.3 and screen 4.1.0 binaries. Again, here
   are more than one option to do so:

   1) Let the preinst maintainer script make a copy of the old screen
      binary, provide a script to clean up this mess afterwards,
      inform the user via debconf about the issue and his
      possibilities (where the copy of the old screen is, etc.).

      Disadvantage: It's a non-dpkg-managed mess.

   2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
      i.e. give them different source and binary package names.

      Disadvantage: Dependencies between those packages needed for
      proper Wheezy migration not obvious. We'd need something like
      "if screen sessions are running, pull in screen-4.0.3 and
      screen-4.1.0, but just pull in screen-4.1.0 if no screen session
      is running", but of course this is impossible just with
      dependencies.

Additionally, I'm not 100% (but let's say 90% :-) convinced that these
changes necessarily had to be incompatible. But changing them back (if
possible) would surely have some impact the other way round for those
already running git snapshots running with the current protocol
version. So there may be also an option "D":

D) Convince upstream to make the new protocol (which includes password
   protected screen sessions even after reattaching) compatible to the
   old protocol.

IMHO option A would be the most preferable one, D seems less
realistic, C2 is realistic but quite some work, B1, B3 and C1 are
ugly, and B2 is said to possibly become ugly, too.

So my current plan is that if nobody manages A, I'd have a closer look
at C2 and if that's not possible or too complicated, I'd go with B2
and the mentioned Debconf questions as the last resort.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #82 received at 644788@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 03:57:42 +0100

[Message part 1 (text/plain, inline)]

On Jan 02, Axel Beckert <abe@debian.org> wrote:

> A) Add an option to screen so the screen client speaks the old
>    protocol to the running server protocol. This IMHO would be best
>    solution and one without a big impact. It's also something which
As long as the needed patch is simple. But if it were, this would 
probably already have been solved.

>    2) Fail in the preinst maintainer script if screen server processes
>       are running like udev did from Etch to Lenny if not upgraded
>       together with the kernel.
The abort notice should be provided by debconf before the upgrade 
process is started, indeed.

>    1) Let the preinst maintainer script make a copy of the old screen
>       binary, provide a script to clean up this mess afterwards,
>       inform the user via debconf about the issue and his
>       possibilities (where the copy of the old screen is, etc.).
> 
>       Disadvantage: It's a non-dpkg-managed mess.
I strongly recommend this solution, along with a proper debconf notice.
If screen is running, the admin will be able to choose between:
- abort the upgrade, upgrade screen and its dependencies and then 
  start again the full upgrade
- continue the upgrade while knowing that the old binary will still be
  available in /tmp/old-screen.$RANDOM/ or something

/tmp is a good choice because the next reboot will automatically clean 
up everything (and obviously the old binary will not be needed after 
a reboot).

>    2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
>       i.e. give them different source and binary package names.
This would require a great amount of work to fix a tiny problem which 
presents itself just for the length of the upgrade process, if at all.

I believe that this is a textbook example which shows how trying to 
implement the perfect solution which will beautifully cover all corner 
cases has indefinitly stalled development on the package.
Do not try to fix everything, you should aim to provide a reasonable 
solution which will solve the most common cases.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #87 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 04:13:44 +0100

Hi Marco,

Marco d'Itri wrote:
> >    1) Let the preinst maintainer script make a copy of the old screen
> >       binary, provide a script to clean up this mess afterwards,
> >       inform the user via debconf about the issue and his
> >       possibilities (where the copy of the old screen is, etc.).
> > 
> >       Disadvantage: It's a non-dpkg-managed mess.
> I strongly recommend this solution, along with a proper debconf notice.
[...]
> /tmp is a good choice because the next reboot will automatically clean 
> up everything (and obviously the old binary will not be needed after 
> a reboot).

Thanks for that hint. This sounds better (and especially less messy)
than I thought! :-)

> >    2) Make screen 4.0.3 and screen 4.1.0 installable at the same time,
> >       i.e. give them different source and binary package names.
> This would require a great amount of work

I fear so, yes.

> to fix a tiny problem which presents itself just for the length of
> the upgrade process, if at all.

Correct. It's an option nevertheless, so I mentioned it.

Thanks for your insight!

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #92 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Ben Finney <ben+debian@benfinney.id.au>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 02 Jan 2012 15:17:07 +1100

Axel Beckert <abe@debian.org> writes:

> A) Add an option to screen so the screen client speaks the old
>    protocol to the running server protocol. This IMHO would be best
>    solution and one without a big impact. It's also something which
>    could be Debian-only, i.e. a patch. (It of course would be better
>    if upstream could be convinced to add such an option. :-)

That does sound like the best option. Reading upstream's latest
response, they don't seem to have expressed a position on accepting such
a change if someone does the work to implement it.

> B) Take care that nobody upgrades the screen package while running
>    inside a screen without being aware of the possible problems. There
>    are few ideas how to implement this:
>
>    1) Mention it in the release notes that screen has to be upgraded
>       to the very end of the dist-upgrade process if the dist-upgrade
>       is running inside screen.
>
>       Disadvantage: Many admins don't read the release notes.
[…]
>    3) Tell people via the release notes that they should not run the
>       dist-upgrade inside screen, but inside tmux instead.
>
>       Disadvantage: Many admins don't read the release notes.

The release notes (by which I assume you mean ‘changelog’ and
‘changelog.Debian’) are not displayed by default, but I think the
‘NEWS.Debian’ file is intended for this sort of “you need to know this
before upgrading the package to this version” information. See the
Developer's Reference §6.3.4.

-- 
 \           “I am as agnostic about God as I am about fairies and the |
  `\           Flying Spaghetti Monster.” —Richard Dawkins, 2006-10-13 |
_o__)                                                                  |
Ben Finney <ben@benfinney.id.au>

Message #97 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 05:29:48 +0100

Hi Ben,

Ben Finney wrote:
> > B) Take care that nobody upgrades the screen package while running
> >    inside a screen without being aware of the possible problems. There
> >    are few ideas how to implement this:
> >
> >    1) Mention it in the release notes that screen has to be upgraded
> >       to the very end of the dist-upgrade process if the dist-upgrade
> >       is running inside screen.
> >
> >       Disadvantage: Many admins don't read the release notes.
> […]
> >    3) Tell people via the release notes that they should not run the
> >       dist-upgrade inside screen, but inside tmux instead.
> >
> >       Disadvantage: Many admins don't read the release notes.
> 
> The release notes (by which I assume you mean ‘changelog’ and
> ‘changelog.Debian’)

Nope. I mean the release notes as published by Debian when releasing a
new stable release, i.e.
http://www.debian.org/releases/stable/releasenotes tracked at
http://bugs.debian.org/release-notes

> but I think the ‘NEWS.Debian’ file is intended for this sort of “you
> need to know this before upgrading the package to this version”
> information.

It's already in there since the last upload to experimental.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #102 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Romain Francoise <rfrancoise@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 02 Jan 2012 09:28:39 +0100

Axel Beckert <abe@debian.org> writes:

>    3) Tell people via the release notes that they should not run the
>       dist-upgrade inside screen, but inside tmux instead.

Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades,
the socket path was changed from /var/run/tmux to /tmp in order to remove
the setgid bit from the binary. So while the protocol itself hasn't
changed, the new tmux won't see the old servers unless given the path
explicitly (as documented in NEWS.Debian).

-- 
Romain Francoise <rfrancoise@debian.org>
http://people.debian.org/~rfrancoise/

Message #107 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org, 649240@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 14:01:47 +0100

Hi,

Romain Francoise wrote:
> >    3) Tell people via the release notes that they should not run the
> >       dist-upgrade inside screen, but inside tmux instead.
> 
> Unfortunately tmux has an issue of its own for squeeze → wheezy upgrades,

.oO( Houston, we've got a problem. )

> the socket path was changed from /var/run/tmux to /tmp in order to
> remove the setgid bit from the binary. So while the protocol itself
> hasn't changed, the new tmux won't see the old servers unless given
> the path explicitly (as documented in NEWS.Debian).

Ok, but that either involves some more commandline options or some
symbolic link(s) and is therefore do-able for every better admin (i.e.
those who read documentation). *phew* :-)

Thanks for the information!

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #112 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 19:23:25 +0100

On Mon, Jan  2, 2012 at 03:18:34 +0100, Axel Beckert wrote:

> A) Add an option to screen so the screen client speaks the old
>    protocol to the running server protocol. This IMHO would be best
>    solution and one without a big impact. It's also something which
>    could be Debian-only, i.e. a patch. (It of course would be better
>    if upstream could be convinced to add such an option. :-)
> 
Why would that need an option?  Can't the protocol version be discovered
on connection?

Cheers,
Julien

Message #117 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 19:47:03 +0100

Hi Julien,

Julien Cristau wrote:
> > A) Add an option to screen so the screen client speaks the old
> >    protocol to the running server protocol. This IMHO would be best
> >    solution and one without a big impact. It's also something which
> >    could be Debian-only, i.e. a patch. (It of course would be better
> >    if upstream could be convinced to add such an option. :-)
>
> Why would that need an option?  Can't the protocol version be discovered
> on connection?

Good point.

I suspect that the current code doesn't do that: screen 4.1.0 IIRC
just hangs when it tries to speak with a 4.0.3 server. I suspect that
this part is not yet so sophisticated since it's (according to the
commit message) the first time they ever bumped the protocol version.
The two processes seem to tell each other which protocol version they
speak and then don't care about it anymore. :-/

Of course, auto-detection would be perfect (if implemented by
upstream), but I suspect that as scope for a Debian-specific patch the
command-line option would be easier to implement.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #122 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Yaroslav Halchenko <debian@onerussian.com>

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Mon, 2 Jan 2012 16:26:55 -0500

On Mon, 02 Jan 2012, Axel Beckert wrote:
> > I strongly recommend this solution, along with a proper debconf notice.
> [...]
> > /tmp is a good choice because the next reboot will automatically clean 
> > up everything (and obviously the old binary will not be needed after 
> > a reboot).
> Thanks for that hint. This sounds better (and especially less messy)
> than I thought! :-)

Thank you Axel for your detailed response and IMHO this is indeed close
to an ideal (lightweight, self-cleaning, etc) resolution for this
scenario.  BTW -- what is the take of standards/practices on having /tmp
mounted with noexec [1]?  I just wondered if that might be worth a
check/warning during moving the binary

[1] http://serverfault.com/questions/72356/how-useful-is-mounting-tmp-noexec

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

Message #127 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 07:17:04 +0100

Hi Yaroslav!

Yaroslav Halchenko wrote:
> > > I strongly recommend this solution, along with a proper debconf notice.
> > [...]
> > > /tmp is a good choice because the next reboot will automatically clean 
> > > up everything (and obviously the old binary will not be needed after 
> > > a reboot).
> > Thanks for that hint. This sounds better (and especially less messy)
> > than I thought! :-)
> 
> Thank you Axel for your detailed response and IMHO this is indeed close
> to an ideal (lightweight, self-cleaning, etc) resolution for this
> scenario.  BTW -- what is the take of standards/practices on having /tmp
> mounted with noexec [1]?

Good point! /run/shm (IIRC formerly /dev/shm) likely would be an
alternative option, too.

> I just wondered if that might be worth a check/warning during moving
> the binary

Indeed. Thanks for this hint!

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #132 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 10:05:46 +0000

On Tue, Jan 03, 2012 at 07:17:04AM +0100, Axel Beckert wrote:
> Hi Yaroslav!
> 
> Yaroslav Halchenko wrote:
> > > > I strongly recommend this solution, along with a proper debconf notice.
> > > [...]
> > > > /tmp is a good choice because the next reboot will automatically clean 
> > > > up everything (and obviously the old binary will not be needed after 
> > > > a reboot).
> > > Thanks for that hint. This sounds better (and especially less messy)
> > > than I thought! :-)
> > 
> > Thank you Axel for your detailed response and IMHO this is indeed close
> > to an ideal (lightweight, self-cleaning, etc) resolution for this
> > scenario.  BTW -- what is the take of standards/practices on having /tmp
> > mounted with noexec [1]?
> 
> Good point! /run/shm (IIRC formerly /dev/shm) likely would be an
> alternative option, too.

No, it would not.  This directory is reserved for the eglibc
POSIX SHM/SEM interfaces.  Please don't abuse it--we only just
moved all the existing abusers to /run!  Nothing other than
eglibc has any business creating files there, ever.

If you really need to use a filesystem mounted noexec, just run
the binary via /lib/ld.so (you'll need to get the real location
from e.g. ldd).  Something like:

  LD=$(ldd /tmp/path/to/screen | grep "ld-${arch}" | sed -e 's/[[:space:]]*\(\/[^[:space:]]*\)[[:space:]].*/\1/')
  "$LD" /tmp/screen-94skls/screen

Or query for DT_INTERP directly and run that.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #137 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Yaroslav Halchenko <debian@onerussian.com>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 08:55:54 -0500

just thought of it: another possible complication of this approach (mv
/usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
screen (e.g. byobu) might be in the cold water if the default screen in
the PATH cannot do its duties.

FWIW:

$> apt-cache rdepends screen
screen
Reverse Depends:
  apt-dater
  winpdb
  surfraw-extra
  surfraw
  screenie
 |rtorrent
  podracer
  narval-utils
  mdm
  iselect
  epoptes-client
  education-common
  cereal
  byobu
  apt-dater


> > > /tmp is a good choice because the next reboot will automatically clean 
> > > up everything (and obviously the old binary will not be needed after 
> > > a reboot).
> > Thanks for that hint. This sounds better (and especially less messy)
> > than I thought! :-)

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

Message #142 received at 644788@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 14:56:50 +0100

[Message part 1 (text/plain, inline)]

On Jan 03, Yaroslav Halchenko <debian@onerussian.com> wrote:

> just thought of it: another possible complication of this approach (mv
> /usr/bin/screen /tmp/screen-4.0) might be -- tools depending on
> screen (e.g. byobu) might be in the cold water if the default screen in
> the PATH cannot do its duties.
It does not matter, this is needed strictly for the time of the upgrade 
process.
Stop overengineering.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #147 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 16:04:04 +0100

Hi,

Roger Leigh wrote:
[/tmp mounted noexec]
> > /run/shm (IIRC formerly /dev/shm) likely would be an
> > alternative option, too.
> 
> No, it would not.  This directory is reserved for the eglibc
> POSIX SHM/SEM interfaces.

Thanks for this explanation. It's the first time I read or hear about
the purpose of this mountpoint although I wondered about its purpose
for years now. (But never actively tried to find out. :-)

Bastian Blank wrote:
> On Tue, Jan 03, 2012 at 10:05:46AM +0000, Roger Leigh wrote:
> > If you really need to use a filesystem mounted noexec, just run
> > the binary via /lib/ld.so (you'll need to get the real location
> > from e.g. ldd).  Something like:
> 
> The kernel does not allow executable mappings from noexec filesystems,
> so this does not work.
> 
> | $ /lib64/ld-linux-x86-64.so.2 ./ls 
> | ./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted

Thanks for the comment. Cc'ing the relevant bug again, as this is
crucial information when I work on fixing the bug.

Roger Leigh wrote:
> Or query for DT_INTERP directly and run that.

Never heard of that before. Searching the web just found hits
indicating it seems part of the ELF header. No idea how to work with
it, though. Any hints?

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #152 received at 644788@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 16:43:34 +0100

[Message part 1 (text/plain, inline)]

On Jan 03, Axel Beckert <abe@debian.org> wrote:

> Thanks for the comment. Cc'ing the relevant bug again, as this is
> crucial information when I work on fixing the bug.
If /tmp is noexec then the administrator mounted it this way and knows
about it. So if he is smart enought to mount /tmp noexec then he can
probably understand that he needs to copy the old binary somewhere else
if and when it will be needed.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #157 received at 644788@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

Cc: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 16:47:49 +0100

[Message part 1 (text/plain, inline)]

On Jan 03, Edward Allcutt <edward@allcutt.me.uk> wrote:

> On Tue, 3 Jan 2012, Marco d'Itri wrote:
> >It does not matter, this is needed strictly for the time of the upgrade
> >process.
> Just how short do you expect this to be? I'm sure many of us
> dist-upgrade daily and (shock! horror!) don't reboot after each
> upgrade.
This is only relevant for stable to stable upgrades, if you use testing 
or unstable then you are supposed to be able to cope with such things.

> We also don't expect existing processes to break or become
> inaccessible after an upgrade.
This is why you will get a debconf notice which will inform you about
the needed workaround if you want to continue the upgrade and do not 
reboot soon after it.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #162 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Edward Allcutt <edward@allcutt.me.uk>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 15:43:03 +0000 (GMT)

On Tue, 3 Jan 2012, Marco d'Itri wrote:
> It does not matter, this is needed strictly for the time of the upgrade
> process.

Just how short do you expect this to be? I'm sure many of us dist-upgrade 
daily and (shock! horror!) don't reboot after each upgrade. We also don't 
expect existing processes to break or become inaccessible after an 
upgrade.

I mean, I'll probably cope, but it's not quite the smooth, seamless 
experience that I generally expect.

-- 
Edward Allcutt
Who doesn't expect to reboot unless the kernel has changed.

Message #167 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 16:58:08 +0100

Hi,

Marco d'Itri wrote:
> If /tmp is noexec then the administrator mounted it this way and knows
> about it.

Yeah, but that is possibly such a long time ago that it's not the
first thought. So a small hint to fresh up the memory can't be bad.

> So if he is smart enought to mount /tmp noexec then he can probably
> understand that he needs to copy the old binary somewhere else if
> and when it will be needed.

Yeah, and mentioning exactly this in the debconf notice makes it user
friendly, too.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #172 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Didier Raboud <odyx@debian.org>

To: Axel Beckert <abe@debian.org>

Cc: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 17:10:49 +0100

[Message part 1 (text/plain, inline)]

Le mardi, 3 janvier 2012 16.58:08, Axel Beckert a écrit :
> Hi,
> 
> Marco d'Itri wrote:
> > If /tmp is noexec then the administrator mounted it this way and knows
> > about it.

Another idea would be to use /usr/bin as temporary place for the old screen. 
That would be a Policy violation but not a much "bigger" than using /tmp .

1) in screen/wheezy's `preinst upgrade`:
	cp /usr/bin/screen /usr/bin/screen-old
	touch /tmp/flag-screen-has-been-upgraded-no-reboot-yet
	(+ appropriate mktemp and usual version and sanity checks)
	
2) This means that as long as the machine hasn't been rebooted (/tmp emptied), 
both the new /usr/bin/screen and the old /usr/bin/screen-old exist for the 
admin to use.

3) In a "screen-cleanup init script", test the inexistance of the flag and the 
existance of /usr/bin/screen-old; in that case, `rm` it.
	(+ appropriate version and sanity checks, + idempotency)

This is mostly the "put it under /tmp" idea minus the "noexec" caveat, plus 
the "init script insanity" (which can be dropped in unstable as soon as Wheezy 
is released).

Opinions ?

OdyX

[signature.asc (application/pgp-signature, inline)]

Message #177 received at 644788@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

Cc: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 17:17:25 +0100

[Message part 1 (text/plain, inline)]

On Jan 03, Didier Raboud <odyx@debian.org> wrote:

> 3) In a "screen-cleanup init script", test the inexistance of the flag and the 
> existance of /usr/bin/screen-old; in that case, `rm` it.
> 	(+ appropriate version and sanity checks, + idempotency)
This is bad, because to solve a possible 30 minutes issue you add an 
init script which slows down the boot process of every user for the 
whole life of the release.
Do not overengineer.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #182 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Romain Francoise <rfrancoise@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 03 Jan 2012 17:40:16 +0100

Yaroslav Halchenko <debian@onerussian.com> writes:

> Thank you Axel for your detailed response and IMHO this is indeed close
> to an ideal (lightweight, self-cleaning, etc) resolution for this
> scenario.

Of course the real lightweight, self-cleaning solution is to not do
anything special as the old binary will be kept by the kernel as
/proc/<serverpid>/exe and can be used to reattach as long as the server is
running. But I guess that for the sake of non-Linux users, keeping a copy
in /tmp is more reasonable...

-- 
Romain Francoise <rfrancoise@debian.org>
http://people.debian.org/~rfrancoise/

Message #187 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 3 Jan 2012 17:55:04 +0100

Hi,

Romain Francoise wrote:
> > Thank you Axel for your detailed response and IMHO this is indeed close
> > to an ideal (lightweight, self-cleaning, etc) resolution for this
> > scenario.
> 
> Of course the real lightweight, self-cleaning solution is to not do
> anything special as the old binary will be kept by the kernel as
> /proc/<serverpid>/exe and can be used to reattach as long as the server is
> running.

Yes and no.

First, this seems to be just some (kind of) symbolic link:

lrwxrwxrwx 1 root root 0 Jan  3 17:49 /proc/32039/exe -> /usr/bin/screen (deleted)

And I can't really execute it, neither as the user owning the screen
session nor as root:

~ # /proc/32039/exe -ls
zsh: permission denied: /proc/32039/exe

Not sure if that's because of this fake symlink or due to other
reasons, though.

> But I guess that for the sake of non-Linux users, keeping a copy
> in /tmp is more reasonable...

That, too. Nevertheless, it would have been a tempting solution.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #192 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Romain Francoise <rfrancoise@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 03 Jan 2012 19:58:05 +0100

Axel Beckert <abe@debian.org> writes:

> And I can't really execute it, neither as the user owning the screen
> session nor as root:

> ~ # /proc/32039/exe -ls
> zsh: permission denied: /proc/32039/exe

Yes, /proc is mounted noexec so you need to use the ld-linux.so trick.

But now that I actually try it, I realize that it makes screen lose its
setgid bit, so it doesn't actually work in this context:

root@silenus:~# screen -ls
There is a screen on:
        12255.pts-17.silenus    (01/03/2012 07:44:49 PM)        (Detached)
1 Socket in /var/run/screen/S-root.
root@silenus:~# rm /usr/bin/screen
root@silenus:~# file -L /proc/12255/exe
/proc/12255/exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0xc95e778d3362448aa7bfe3191f007d225652dc0a, stripped
root@silenus:~# /proc/12255/exe -ls
-su: /proc/12255/exe: Permission denied
root@silenus:~# /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /proc/12255/exe -ls
Directory '/var/run/screen' must have mode 777.
root@silenus:~#

Sorry for the false alarm. :)

-- 
Romain Francoise <rfrancoise@debian.org>
http://people.debian.org/~rfrancoise/

Message #197 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Wed, 04 Jan 2012 10:47:00 +0100

]] Axel Beckert 

> I see the following options:

[...]

Not really a serious suggestion, but for completeness

E) ignore the problem and just let people rescue the programs stuck in
the old screen using retty, reptyr or similar.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #202 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Wed, 4 Jan 2012 11:00:00 +0100

Hi Tollef,

Tollef Fog Heen wrote:
> Not really a serious suggestion, but for completeness
> 
> E) ignore the problem and just let people rescue the programs stuck in
> the old screen using retty, reptyr or similar.

My experiences with one of these tools (IIRC retty, but I'm not sure)
a few years ago were not very successful so I did not take this option
into account. Haven't tried any other tools since then.

Additionally, rescueing apt or aptitude if the according tool is not
yet installed is likely impossible without killing the running
apt/aptitude to install that tool.

But yeah, if we have options which are not much
work, but assist the admins in the dist-upgrade a lot, all less
comfortable or rough options, like this, can be ignored.

Thanks for the comment anyway. I learned that there is more than one
tool which could fetch a running program into screen. :-)

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #207 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Wed, 4 Jan 2012 11:21:03 +0000

On Tue, Jan 03, 2012 at 04:04:04PM +0100, Axel Beckert wrote:
> Hi,
> 
> Roger Leigh wrote:
> [/tmp mounted noexec]
> > > /run/shm (IIRC formerly /dev/shm) likely would be an
> > > alternative option, too.
> > 
> > No, it would not.  This directory is reserved for the eglibc
> > POSIX SHM/SEM interfaces.
> 
> Thanks for this explanation. It's the first time I read or hear about
> the purpose of this mountpoint although I wondered about its purpose
> for years now. (But never actively tried to find out. :-)

shm_overview(7) has some background.  It's not obvious it's in use
because most users unlink their file as soon as it's created, giving
the false impression it's empty!

> Bastian Blank wrote:
> > On Tue, Jan 03, 2012 at 10:05:46AM +0000, Roger Leigh wrote:
> > > If you really need to use a filesystem mounted noexec, just run
> > > the binary via /lib/ld.so (you'll need to get the real location
> > > from e.g. ldd).  Something like:
> > 
> > The kernel does not allow executable mappings from noexec filesystems,
> > so this does not work.
> > 
> > | $ /lib64/ld-linux-x86-64.so.2 ./ls 
> > | ./ls: error while loading shared libraries: ./ls: failed to map segment from shared object: Operation not permitted
> 
> Thanks for the comment. Cc'ing the relevant bug again, as this is
> crucial information when I work on fixing the bug.
> 
> Roger Leigh wrote:
> > Or query for DT_INTERP directly and run that.
> 
> Never heard of that before. Searching the web just found hits
> indicating it seems part of the ELF header. No idea how to work with
> it, though. Any hints?

objdump would probably be the tool of choice.  But if ld.so won't
run programs on noexec filesystems, it's moot.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Message #212 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Wed, 4 Jan 2012 14:04:28 +0000

On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
> On Mon, 02 Jan 2012, Axel Beckert wrote:
> > > /tmp is a good choice because the next reboot will automatically clean 
> > > up everything (and obviously the old binary will not be needed after 
> > > a reboot).
> 
> Thank you Axel for your detailed response and IMHO this is indeed close
> to an ideal (lightweight, self-cleaning, etc) resolution for this
> scenario.  BTW -- what is the take of standards/practices on having /tmp
> mounted with noexec [1]?

Would it be enough for the "your old screen binary is
/tmp/screen-yhpoe8r/screen" notice to also say "if your /tmp is mounted
noexec, you might need to copy it elsewhere to run it"? Or you could just
assume that any sysadmin who has deliberately enabled noexec (not the default,
after all) is able to realise (and deal with) the consequences :-)

    S

Message #217 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Wed, 4 Jan 2012 15:24:06 +0100

Hi Simon,

Simon McVittie wrote:
> On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
> > On Mon, 02 Jan 2012, Axel Beckert wrote:
> > > > /tmp is a good choice because the next reboot will automatically clean 
> > > > up everything (and obviously the old binary will not be needed after 
> > > > a reboot).
> > 
> > Thank you Axel for your detailed response and IMHO this is indeed close
> > to an ideal (lightweight, self-cleaning, etc) resolution for this
> > scenario.  BTW -- what is the take of standards/practices on having /tmp
> > mounted with noexec [1]?
> 
> Would it be enough for the "your old screen binary is
> /tmp/screen-yhpoe8r/screen" notice to also say "if your /tmp is mounted
> noexec, you might need to copy it elsewhere to run it"?

That's my current plan -- with the noexec notice just being displayed
if /tmp actually is mounted noexec.

> Or you could just assume that any sysadmin who has deliberately
> enabled noexec (not the default, after all) is able to realise (and
> deal with) the consequences :-)

As I wrote in another mail, you once enable this and forget about it
then, after years, wonder, why some upgraded software suddenly behaves
strangely. BTDT. :-)

So I think it's more admin friendly to write a nice reminder.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #222 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Matthew Woodcraft <matthew@woodcraft.me.uk>

To: debian-devel@lists.debian.org

Cc: 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Wed, 4 Jan 2012 20:05:37 +0000

Axel Beckert  <abe@debian.org> wrote:

>Simon McVittie wrote:
>> Would it be enough for the "your old screen binary is
>> /tmp/screen-yhpoe8r/screen" notice to also say "if your /tmp is mounted
>> noexec, you might need to copy it elsewhere to run it"?

> That's my current plan -- with the noexec notice just being displayed
> if /tmp actually is mounted noexec.

Will you need something similar if /tmp is mounted nosuid? I think
that's more common.

-M-

Message #227 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: debian-devel@lists.debian.org, 644788@bugs.debian.org

Subject: Re: Bug#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation

Date: Tue, 10 Jan 2012 19:00:35 +0800

On 01/04/2012 10:24 PM, Axel Beckert wrote:
> Hi Simon,
>
> Simon McVittie wrote:
>   
>> On Mon, 02 Jan 2012 at 16:26:55 -0500, Yaroslav Halchenko wrote:
>>     
>>> On Mon, 02 Jan 2012, Axel Beckert wrote:
>>>       
>>>>> /tmp is a good choice because the next reboot will automatically clean 
>>>>> up everything (and obviously the old binary will not be needed after 
>>>>> a reboot).
>>>>>           
>>> Thank you Axel for your detailed response and IMHO this is indeed close
>>> to an ideal (lightweight, self-cleaning, etc) resolution for this
>>> scenario.  BTW -- what is the take of standards/practices on having /tmp
>>> mounted with noexec [1]?
>>>       
>> Would it be enough for the "your old screen binary is
>> /tmp/screen-yhpoe8r/screen" notice to also say "if your /tmp is mounted
>> noexec, you might need to copy it elsewhere to run it"?
>>     
> That's my current plan -- with the noexec notice just being displayed
> if /tmp actually is mounted noexec.
>   

Good plan, but I'd also vouch for few lines in the release notes, still.
Even you are planning on doing it with debconf, which after all,
is the only thing we should do (just echoing on the console is bad).

Thomas

Message #232 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: sadrul@chromium.org

Cc: Screen development <screen-devel@gnu.org>, 644788@bugs.debian.org

Subject: Re: [screen-devel] Request for new stable release

Date: Mon, 6 Feb 2012 11:21:22 +0100

Hi Sadrul,

On Sun, Feb 05, 2012 at 06:34:18PM -0500, Sadrul Habib Chowdhury wrote
in <https://lists.gnu.org/archive/html/screen-devel/2012-02/msg00004.html>:
> Hi! I had plans to do a beta-release last week. It hasn't quite happened
> yet. I was trying to get in some changes that would allow a
> screen-4.0.1beta client to attach to a screen-4.0.3 server, so that users
> would be able to connect to old screen sessions after upgrade.

Yay! That's slightly unexpected but very good news for me. Thanks for
looking into that issue and thanks for informing about you working on
it.

> It's still not quite there yet, so the release hasn't happened. If I
> can't get it done within this week, I expect to go ahead with the
> beta lease next weekend.

Very looking forward to it!

Thanks again.

		Kind regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #241 received at 644788-close@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 644788-close@bugs.debian.org

Subject: Bug#644788: fixed in screen 4.1.0~20120320gitdb59704-2

Date: Sun, 10 Jun 2012 18:49:32 +0000

Source: screen
Source-Version: 4.1.0~20120320gitdb59704-2

We believe that the bug you reported is fixed in the latest version of
screen, which is due to be installed in the Debian FTP archive:

screen_4.1.0~20120320gitdb59704-2.debian.tar.gz
  to main/s/screen/screen_4.1.0~20120320gitdb59704-2.debian.tar.gz
screen_4.1.0~20120320gitdb59704-2.dsc
  to main/s/screen/screen_4.1.0~20120320gitdb59704-2.dsc
screen_4.1.0~20120320gitdb59704-2_amd64.deb
  to main/s/screen/screen_4.1.0~20120320gitdb59704-2_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 644788@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Axel Beckert <abe@debian.org> (supplier of updated screen package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 10 Jun 2012 17:54:53 +0200
Source: screen
Binary: screen
Architecture: source amd64
Version: 4.1.0~20120320gitdb59704-2
Distribution: unstable
Urgency: low
Maintainer: Axel Beckert <abe@debian.org>
Changed-By: Axel Beckert <abe@debian.org>
Description: 
 screen     - terminal multiplexor with VT100/ANSI terminal emulation
Closes: 644788 660567
Changes: 
 screen (4.1.0~20120320gitdb59704-2) unstable; urgency=low
 .
   * Upload to unstable as the two RC issues which the experimental package
     had, are now resolved or at least workarounded:
     - Copy /usr/bin/screen to /tmp/screen-4.0.3 on upgrade from pre-4.1.0
       and use debconf to inform the user about it. (Closes: #644788)
     - Add patch to fix terminal handling on kfreebsd (Closes: #660567)
       Thanks Jan Christoph Nordholz!
   * Add patch to fix parallel building.
   * Use dh_lintian instead of handling lintian overrides manually.
   * No more clean up manually what dh_clean can clean up.
   * Add new patch to fix man page errors and warnings:
     - Lintian warning manpage-has-errors-from-man fixed by replacing all
       occurrences of "..." by "…"
     - Fixes tons of lintian warnings hyphen-used-as-minus-sign
     - Added two false positives of hyphen-used-as-minus-sign to
       lintian-overrides
     - Fixes two typos found by lintian
     - Update 80EXP_session_creation_time.patch accordingly
Checksums-Sha1: 
 30e28abe38bf570161c2dc3993557d63014e6f83 1458 screen_4.1.0~20120320gitdb59704-2.dsc
 707f5b4f28c3052a176b42bc4b3d9f849db9625a 60417 screen_4.1.0~20120320gitdb59704-2.debian.tar.gz
 7d31e5beb8baa109fc624825c66b4ff94772d036 667332 screen_4.1.0~20120320gitdb59704-2_amd64.deb
Checksums-Sha256: 
 2f5945b8c037514216375f6dc8b796cdf7e317ed6e56677e82715132e33e71f4 1458 screen_4.1.0~20120320gitdb59704-2.dsc
 d2b5741ee96efe13fc4bec1c375dac41430b5fac7c71db35861e39d73f9d22c2 60417 screen_4.1.0~20120320gitdb59704-2.debian.tar.gz
 d5ccc5999683978f08f58d869001b3fe25c3d2db491d6af27ed4d39dab1da2da 667332 screen_4.1.0~20120320gitdb59704-2_amd64.deb
Files: 
 a6046f4fde87a34430888eb242042db7 1458 misc optional screen_4.1.0~20120320gitdb59704-2.dsc
 9e6788b9f77999cc94d04a89ca64e902 60417 misc optional screen_4.1.0~20120320gitdb59704-2.debian.tar.gz
 58666ed78bab0cbd2e228b77538730f5 667332 misc optional screen_4.1.0~20120320gitdb59704-2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk/U2MEACgkQwJ4diZWTDt49jQCeNT5Yj7UbtOxoTCHNTO18mvAG
O2MAn2abrfQNIb+BlHU0j9RvtVX7MhdH
=YQy1
-----END PGP SIGNATURE-----

Message #246 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Samuel Thibault <sthibault@debian.org>

To: Axel Beckert <abe@debian.org>

Cc: 522689@bugs.debian.org, 660567@bugs.debian.org, 644788@bugs.debian.orgr

Subject: Re: Bug#522689: screen: GNU/kFreeBSD fix breaks GNU/Hurd

Date: Mon, 11 Jun 2012 14:45:18 +0200

Axel Beckert, le Fri 08 Jun 2012 12:31:26 +0200, a écrit :
> The second reason for not uploading to unstable yet has been resolved
> last week, but it may affect usability on Hurd, too, again:
> 
> 4.1.0 failed on kfreebsd again (http://bugs.debian.org/660567) and
> thanks to Jan Christoph Nordholz I was able to fix it on kfreebsd a
> few days ago.
> 
> Would you be so kind to check that my new patch
> (http://anonscm.debian.org/gitweb/?p=collab-maint/screen.git;a=commitdiff;h=7d2ca279)
> works properly on Hurd, too?

I didn't find the time to test before your upload, but I could test the
built package and it looks fine.

Samuel

Message #251 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: 677227@bugs.debian.org

Cc: 644788@bugs.debian.org, debian-bsd@lists.debian.org

Subject: Re: Bug#677227: screen: Workaround for #644788 fails to detect a running screen on kfreebsd / process renaming does not work on kfreebsd

Date: Tue, 12 Jun 2012 15:38:06 +0200

Hi,

some more details:

Axel Beckert wrote:
> [...] on kfreebsd this process renaming don't seem to work. This doesn't
> seem to be a screen issue but a general kfreebsd issue as the following
> works as expected on Linux, but not on kfreebsd:
> 
> $ perl -e '$0 = "foobar!"; <>'

JFTR: hurd-i386 seems not to be affected, works as expected there,
too.

> Happened with kernel 8.2-1-686-smp which seems no more to be available.
> Will test later if it still happens with current kernels and if so, file
> a seperated bug report against some kfreebsd-image-* packages.

According to lifeng on IRC the same happens with our 9.0 kernel, too.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #260 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: sadrul@chromium.org

Cc: screen-devel@gnu.org, 644788@bugs.debian.org

Subject: State of reattaching to a 4.0.3 session with a 4.1.0 client? (was: Re: [screen-devel] Request for new stable release)

Date: Wed, 25 Jul 2012 16:26:31 +0200

Hi Sadrul,

On Sun, Feb 05, 2012 at 06:34:18PM -0500, Sadrul Habib Chowdhury wrote:
> Hi! I had plans to do a beta-release last week. It hasn't quite happened
> yet. I was trying to get in some changes that would allow a
> screen-4.0.1beta client to attach to a screen-4.0.3 server, so that users
> would be able to connect to old screen sessions after upgrade. It's still
> not quite there yet, so the release hasn't happened. If I can't get it done
> within this week, I expect to go ahead with the beta lease next weekend.

Any news here? I'd really like to see that fixed properly for the
upcoming Debian release.

We're in freeze for the release now and as of now I just have an ugly
hack which copies the old 4.0.3 binary to /tmp/ before the upgrade so
it's still available for reattaching after e.g. connection loss.

		Kind regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Message #265 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Steve Langasek <vorlon@debian.org>, 649240@bugs.debian.org

Cc: Justin B Rye <jbr@edlug.org.uk>, 644788@bugs.debian.org

Subject: Re: Bug#649240: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Thu, 26 Jul 2012 01:30:32 +0200

[Message part 1 (text/plain, inline)]

On Tue, Jul 24, 2012 at 21:17:04 +0200, Julien Cristau wrote:

> Did this stuff ever get fixed?  screen's NEWS.Debian suggests it isn't,
> which I find rather annoying.  Said NEWS file also recommends
> downloading and running code from a random web server as root, which
> really doesn't seem appropriate, even in the context of this bug.  If
> this is indeed the state of screen in wheezy I'm thinking it'd be better
> to go back to the previous (pre-compatibility-break) version.
> 
I'm unimpressed.  Seems like working around this in screen itself is way
simpler than the horrible kludge in the current maintainer scripts.  The
following patch, while not all that pretty, seems to allow me to attach
to a screen started with either the squeeze or sid version.  I'm sure
there's corner cases, but.

Cheers,
Julien

Index: screen-4.1.0~20120320gitdb59704/screen.h
===================================================================
--- screen-4.1.0~20120320gitdb59704.orig/screen.h
+++ screen-4.1.0~20120320gitdb59704/screen.h
@@ -240,6 +240,57 @@ struct msg
     } m;
 };
 
+struct old_msg
+{
+  int protocol_revision;	/* reduce harm done by incompatible messages */
+  int type;
+  char m_tty[MAXPATHLEN];	/* ttyname */
+  union
+    {
+      struct
+	{
+	  int lflag;
+	  int aflag;
+	  int flowflag;
+	  int hheight;		/* size of scrollback buffer */
+	  int nargs;
+	  char line[MAXPATHLEN];
+	  char dir[MAXPATHLEN];
+	  char screenterm[20];	/* is screen really "screen" ? */
+	}
+      create;
+      struct
+	{
+	  char auser[20 + 1];	/* username */
+	  int apid;		/* pid of frontend */
+	  int adaptflag;	/* adapt window size? */
+	  int lines, columns;	/* display size */
+	  char preselect[20];
+	  int esc;		/* his new escape character unless -1 */
+	  int meta_esc;		/* his new meta esc character unless -1 */
+	  char envterm[20 + 1];	/* terminal type */
+	  int encoding;		/* encoding of display */
+	}
+      attach;
+      struct 
+	{
+	  char duser[20 + 1];	/* username */
+	  int dpid;		/* pid of frontend */
+	}
+      detach;
+      struct 
+	{
+	  char auser[20 + 1];	/* username */
+	  int nargs;
+	  char cmd[MAXPATHLEN];	/* command */
+	  int apid;		/* pid of frontend */
+	  char preselect[20];
+	}
+      command;
+      char message[MAXPATHLEN * 2];
+    } m;
+};
+
 /*
  * And the signals the attacher receives from the backend
  */
Index: screen-4.1.0~20120320gitdb59704/socket.c
===================================================================
--- screen-4.1.0~20120320gitdb59704.orig/socket.c
+++ screen-4.1.0~20120320gitdb59704/socket.c
@@ -1067,7 +1067,9 @@ ReceiveMsg()
     }
   if (left > 0)
     {
-      if (left != sizeof(m))
+      if (left == sizeof(struct msg) - sizeof(struct old_msg))
+        ;/* old format message, ignore */
+      else if (left != sizeof(m))
         Msg(0, "Message %d of %d bytes too small", left, (int)sizeof(m));
       else
 	debug("No data on socket.\n");
Index: screen-4.1.0~20120320gitdb59704/attacher.c
===================================================================
--- screen-4.1.0~20120320gitdb59704.orig/attacher.c
+++ screen-4.1.0~20120320gitdb59704/attacher.c
@@ -133,6 +133,46 @@ struct msg *m;
   return 0;
 }
 
+int
+WriteOldMessage(struct msg *m)
+{
+  sleep(1); /* give the server some time to reopen the pipe */
+  if (m->type == MSG_ATTACH && m->m.attach.detachfirst == MSG_ATTACH)
+    {
+      struct old_msg old_m;
+      int s;
+      int r, l = sizeof(old_m);
+
+      s = MakeClientSocket(0);
+      if (s < 0)
+	return 0;
+      old_m.protocol_revision = (('m'<<24) | ('s'<<16) | ('g'<<8) | 0);
+      old_m.type = m->type;
+      memcpy(old_m.m_tty, m->m_tty, sizeof(old_m.m_tty));
+      memcpy(old_m.m.attach.auser, m->m.attach.auser, sizeof(old_m.m.attach.auser));
+      old_m.m.attach.apid = m->m.attach.apid;
+      old_m.m.attach.adaptflag = m->m.attach.adaptflag;
+      old_m.m.attach.lines = m->m.attach.lines;
+      old_m.m.attach.columns = m->m.attach.columns;
+      memcpy(old_m.m.attach.preselect, m->m.attach.preselect, sizeof(old_m.m.attach.preselect));
+      old_m.m.attach.esc = m->m.attach.esc;
+      old_m.m.attach.meta_esc = m->m.attach.meta_esc;
+      memcpy(old_m.m.attach.envterm, m->m.attach.envterm, sizeof(old_m.m.attach.envterm));
+      old_m.m.attach.encoding = m->m.attach.encoding;
+      while(l > 0)
+        {
+          r = write(s, (char *)&old_m + (sizeof(struct old_msg) - l), l);
+          if (r == -1 && errno == EINTR)
+    	continue;
+          if (r == -1 || r == 0)
+    	return -1;
+          l -= r;
+        }
+      close(s);
+    }
+  return 0;
+}
+
 
 int
 Attach(how)
@@ -397,6 +437,7 @@ int how;
   if (WriteMessage(lasts, &m))
     Panic(errno, "WriteMessage");
   close(lasts);
+  WriteOldMessage(&m);
   debug1("Attach(%d): sent\n", m.type);
 #ifdef MULTIUSER
   if (multi && (how == MSG_ATTACH || how == MSG_CONT))

[signature.asc (application/pgp-signature, inline)]

Message #270 received at 644788@bugs.debian.org (full text, mbox, reply):

From: Axel Beckert <abe@debian.org>

To: Julien Cristau <jcristau@debian.org>, 644788@bugs.debian.org

Subject: Re: Bug#644788: Upcoming upgrade issues with GNU Screen for Wheezy

Date: Thu, 26 Jul 2012 23:17:02 +0200

Hi Julien,

Julien Cristau wrote:
> The following patch, while not all that pretty, seems to allow me to
> attach to a screen started with either the squeeze or sid version.

Thanks for the patch. Interesting approach btw.

> I'm sure there's corner cases, but.

I'll test it and will very likely include it in the next upload.
Expect the upload within the upcoming weekend.

I'll also forward it to upstream.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5

Send a report that this bug log contains spam.