Screen crashed during do-release-upgrade, won't resume
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
screen (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I was running "do-release-upgrade -d" to get from 10.04 to 12.04. Partway through, screen (running as byobu) disappeared. I can see that the upgrade is still running and trying to ask me questions I can't answer because I can't reconnect to the screen session.
Expected Result: upgrade runs inside screen and completes
Actual Result: screen crashes making the currently-running upgrade inaccessible to user
<snip earlier upgrade log>
Installing new version of config file /etc/byobu/
Setting up fakeroot (1.18.2-1) ...
Setting up dctrl-tools (2.18ubuntu1) ...
Setting up diffstat (1.54-1) ...
Setting up distro-info-data (0.8ubuntu0.1) ...
Setting up distro-info (0.8.2) ...
Setting up python-distro-info (0.8.2) ...
-------
0*&$ shell 1@$ shell 2@$ shell 3-@$ shell 4@$ shell 5@$ shell maco Menu:<F9>
U 2012-06-01 22:56:17
Error: Cannot find master process to attach to!
maco@lucid:~$
maco@lucid:~$
maco@lucid:~$ screen -r
There is a screen on:
3498.pts-0.lucid (04/09/2012 09:21:02 AM) (Dead ???)
Remove dead screens with 'screen -wipe'.
There is no screen to be resumed.
maco@lucid:~$ ps -ef | grep upgrade
maco 9969 17012 0 23:35 pts/6 00:00:00 grep --color=auto upgrade
root 26066 1 0 18:50 ? 00:00:00 SCREEN -e \0\0 -L -c screenrc -S ubuntu-
root 28183 28167 0 22:56 pts/9 00:00:00 whiptail --backtitle Package configuration --title Configuring postgresql-common --output-fd 11 --nocancel --msgbox Obsolete major version 8.4??The PostgreSQL version 8.4 is obsolete, but the server or client ?packages are still installed. Please install the latest packages ?(postgresql-9.1 and postgresql-
AFAIK screen -ls considers a screen session dead at least when the server crashed but the socket is still there.
I wonder if the opposite ("SCREEN" server still there as your ps output shows, but the socket is gone) could be a reason, too, i.e. if the move from /var/run to /run could be the cause. (Just an idea which should be checked. Will test that. :-)