Subject: Bug#3276: screen upgrade trashes running sessions...

From: [email-masked] (Mark W. Eichin)
Date: 11 Jun 1996 23:23:11 -0400

package: screen
version: 3.7.1-4

screen.postinst has:

#this is to remove the "/tmp/screens has incorrect permissions" after
#upgrading to this (3.7.1) version of screen from 3.6 or earlier.

rm -rf /tmp/screens

This means that if screen is upgraded while someone is using it, they
lose the ability to reattach -- because the pipe gets nuked. I haven't
looked at the sources to see if there is a way to recover (ie. to tell
screen to write a new pipe in place) but in the meantime, it might be
nice to protect this with a "killall -0 screen" and only do the remove
if the exit status of killall is non-zero. (A warning about running
screens might be nice... though if the whole thing is wrapped in a
check for the correct permissions, that would help too...)

---

From: [email-masked] (joost witteveen)
Date: Wed, 12 Jun 1996 20:52:44 +0200 (MET DST)

> version: 3.7.1-4

Hey, the bug tracking mechanism is working again! good.

> lose the ability to reattach -- because the pipe gets nuked.

That's right, and I'd like to add your killall -0 screen idea, but:

> it might be

But what should I do if the exit status *is* non-zero? sacrifice
the working of screen because someone was running at install time?
(if you do have a old screen version, and don't remove the /tmp/screens,
you will not be able to run screen).

Also, what is this about checking the permissions? who's permissions?
Isn't root the only one running the screen.postinst script?

Anyway, thanks for the bug report (and for the spelling error),

-- 
joost witteveen
            [email-masked]
          [email-masked]
--
Use Debian Linux!

---

From: [email-masked] (Mark W. Eichin)
Date: 12 Jun 1996 15:39:05 -0400

> Also, what is this about checking the permissions? who's permissions?

The permissions on /tmp/screens that this rm -rf is intended to fix.
(What brought it to my attention is that I went from 3.7.1-3 to -4,
which clearly *didn't* have anything wrong with /tmp/screens, but it
nuked it anyway.) I'd be happy with that check -- if anyone is still
running a version that does have the permission problem, there isn't
much we can do to save them, I suppose (since a chown/chmod won't
really be "safe".)

---

From: [email-masked] (joost witteveen)
Date: Thu, 13 Jun 1996 00:00:26 +0200 (MET DST)

To correct the problem with screen's postinst always removing /tmp/screens,
thereby cripling currently running processes, I would like to
add the following to the postinst. Could you please check that
this is what we want (I don't want to mess it up real bad just
before the final 1.1 release).

Thanks

[from screen's postinst, 3.7.1-5 (suggested)]:

#this is to remove the "/tmp/screens has incorrect permissions" 
#error message from screen 3.7.1 after upgrading to this (3.7.1)
#version of screen from 3.6 or earlier.

if test  "`ls -ald /tmp/screens|cut -d" " -f 1`" = "drwxr-xr-x"; then
 echo you seem to be upgrading from a post 3.6 version of screen.
 echo "If I'm wrong, plase type \"rm -rf /tmp/screens\" right after"
 echo installation, to avoid problems with permissions later.
else
  if killall -0 screen; then
    echo you seem to be upgrading from a pre-3.7 version of screen,
    echo but you still have screen-sessions running.
    echo This will cause problems with permissions of /tmp/screens,
    echo unless I remove this directory now.
    echo Unfortunately, if I remove /tmp/screens now, the running
    echo screen sessions will loose the ability to reattach.
    echo 
    echo Do you want me to remove /tmp/screens anyway "(adviced)",
    echo thereby cripling the current screen sessions, or shall I 
    echo leave screen unconfigured so that you can rerun the installtion
    echo later, when the screen sessions have ended?
    echo        type 
    echo " 1   to rm -rf /tmp/screens now"
    echo " 2   to leave screen unconfigured"
    read ans  
    if test "$ans" = "1"; then
      rm -rf /tmp/screens
    else
      exit 1
    fi
  else
    echo you seem to be upgrading from a pre-3.7 version of screen.
    echo "to avoid problems with permissions later, I'm now removing"
    echo '/tmp/screens (you should not notice this)'
    rm -rf /tmp/screens
  fi
fi

---

From: [email-masked] (joost witteveen)
Date: Fri, 14 Jun 1996 21:06:26 +0200 (MET DST)

> #upgrading to this (3.7.1) version of screen from 3.6 or earlier.

OK, so I produced a script to correct this, and put it in postinst.

But now I have a real nice riddle: Why doesn't it work?

Answer: dpkg -i screen also runs the postrm from the old screen.
and guess what: it's got a "rm -rf /tmp/screens" too. This is
no surprise, it has to have (otherwise you can never remove
screen completely).

So now what? Make /tmp/screens a "configuration file"? This seems
hardly what "configuration files" were divised for.

Although I agree with you that the current behaviour is less than
perfect, I challenge you to come up with a better way.
(the testing then has to be done in postrm, but postrm *should*
get rid of /tmp/screens).

I could still release screen-3.7.1-5, for the manpage typing
error, but I'm not sure I will.

Anyway, thanks for the most interesting discussion,

---

From: "Darren/Torin/Who Ever..." <[email-masked]>
Date: 14 Jun 1996 16:05:32 -0700

-----BEGIN PGP SIGNED MESSAGE-----

>get rid of /tmp/screens).

Check out the following in node:
(guidelines)Maintainer script arguments and how dpkg does things 

Essentially, you'll only want to rm -rf /tmp/screens when your postinst
gets purge as an argument on the command line.

When upgrading to a new version of screen your old postinst will get an
argument of "upgrade vers-no." on its command line.  If you take a look
there, your scripts and screen users will be happy...

Darren

- -- 
<[email-masked]> <http://www.daft.com/~torin/>    <[email-masked]> <[email-masked]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C/Perl/CGI programmer and tutor. @