^x ^c while running an editor inside do-release-upgrade's screen session disconnects part of the session
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| ubuntu-release-upgrader (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned | ||
Bug Description
on my seldom-used laptop, (running 12.04LTS last updates early august 2013) I ran
sudo do-release-upgrade -p
from bash in a gnome-terminal.
It proceeded fine, until for one of the changed-config-file prompts I had it start a shell to examine the situation. I ran jed, a small emacslike editor, but immediately after I hit ^x ^c to exit jed, the screen session started by do-release-upgrade put up the message that the process had exitted, and did I want to close the screen window or restart the command. Attempted restarts gave the message that the dpkg database was already locked. From another shell, it turned out that jed was actually still running.
I suspect I might have hit the ^x ^c, or maybe the preceding ^x ^s, following a ^space. do-release-upgrade starts screen with the escape character ^space, using the -e option. So to mark a region in an emacslike editor, I needed to get screen to pass through a ^space literally, so I had to press ^space space. I maybe have fumbled this and been in the middle of a screen escape sequence when trying to exit jed. Although neither ^x nor ^c, or even ^s (^x ^s = save in emacslike editors) should have done anything like what I observed, as screen escape commands.
I unfortunately don't still have the situation fully available to poke at, as running firefox on the laptop completely hosed the system. Something must have tried to composite something, but the combination of updated and still running libdrm and nouveau libraries and kernel module just completely did not get along. After a big pause, I was able to switch to a text console, but eventually I just sshed in from my desktop to run ubuntu-bug. Anyway, I no longer have the whole process tree to look at or post, so I'm just working from memory.
The gnome-session - bash - sudo - do-release-upgrade - screen - screen - dpkg - bash - jed
process tree was still there, but I think even at that point, the trusty - dpkg process tree had split off and was a child of init (pid 1).
I've attached the pstree output from the system after exitting X, which killed all the do-release-upgrade stuff. and here's some poking with ps and ls /proc/pid/fd, from an ssh session:
# ps auxw | egrep 'dpkg|trusty'
root 6402 0.0 0.2 22748 9920 pts/1 Ss+ 15:15 0:04 /usr/bin/dpkg --force-overwrite --status-fd 75 --configure ttf-dejavu-core:all libcamel-
root 11781 0.0 0.0 9448 872 pts/11 S+ 23:22 0:00 egrep dpkg|trusty
root 12306 0.8 2.6 288968 106104 ? S 14:32 4:24 /usr/bin/python /tmp/update-
root@abacus:~# ll /proc/12306/fd
total 0
lrwx------ 1 root root 64 Jul 17 23:17 0 -> /dev/pts/4 (deleted)
lrwx------ 1 root root 64 Jul 17 23:17 1 -> /dev/pts/4 (deleted)
lr-x------ 1 root root 64 Jul 17 23:17 10 -> /var/lib/
lr-x------ 1 root root 64 Jul 17 23:17 11 -> /var/lib/
(edit: trimmed out the open file descriptors for more package lists and translations, beween 11 and 70)
lrwx------ 1 root root 64 Jul 17 23:17 2 -> /dev/pts/4 (deleted)
l-wx------ 1 root root 64 Jul 17 23:17 3 -> /var/log/
lrwx------ 1 root root 64 Jul 17 23:17 37 -> /var/log/
lrwx------ 1 root root 64 Jul 17 23:17 38 -> /dev/pts/4 (deleted)
lrwx------ 1 root root 64 Jul 17 23:17 39 -> /var/log/
lr-x------ 1 root root 64 Jul 17 23:17 4 -> pipe:[161795]
lr-x------ 1 root root 64 Jul 17 23:17 40 -> /var/lib/
l-wx------ 1 root root 64 Jul 17 23:17 5 -> pipe:[161795]
l-wx------ 1 root root 64 Jul 17 23:17 6 -> /var/log/
lr-x------ 1 root root 64 Jul 17 23:17 69 -> /var/lib/
lrwx------ 1 root root 64 Jul 17 23:17 7 -> /var/lib/
lr-x------ 1 root root 64 Jul 17 23:17 70 -> /var/lib/
lrwx------ 1 root root 64 Jul 17 23:17 71 -> /var/log/
lrwx------ 1 root root 64 Jul 17 23:17 72 -> /dev/pts/4 (deleted)
l-wx------ 1 root root 64 Jul 17 23:17 73 -> /var/log/
lr-x------ 1 root root 64 Jul 17 23:17 74 -> pipe:[618808]
lrwx------ 1 root root 64 Jul 17 23:17 76 -> /dev/ptmx
lr-x------ 1 root root 64 Jul 17 23:17 8 -> /var/lib/
lr-x------ 1 root root 64 Jul 17 23:17 9 -> /var/lib/
# and the dpkg process
root@abacus:~# ll /proc/6402/fd
total 0
lrwx------ 1 root root 64 Jul 17 15:47 0 -> /dev/pts/1
lrwx------ 1 root root 64 Jul 17 15:47 1 -> /dev/pts/1
lrwx------ 1 root root 64 Jul 17 15:47 2 -> /dev/pts/1
lrwx------ 1 root root 64 Jul 17 15:47 3 -> /var/lib/dpkg/lock
l-wx------ 1 root root 64 Jul 17 15:47 4 -> /var/lib/
lrwx------ 1 root root 64 Jul 17 15:47 5 -> /var/lib/
l-wx------ 1 root root 64 Jul 17 15:47 6 -> /var/log/dpkg.log
lr-x------ 1 root root 64 Jul 17 15:47 7 -> /var/lib/
lrwx------ 1 root root 64 Jul 17 15:47 71 -> /var/log/
lrwx------ 1 root root 64 Jul 17 15:47 72 -> /dev/pts/4 (deleted)
l-wx------ 1 root root 64 Jul 17 15:47 75 -> pipe:[618808]
so the most interesting thing is that the trusty script, and dpkg, are somehow daemonized. They didn't exit when their parent terminal closed. And /dev/pts/1 isn't even deleted, even though the screen session is dead. I believe that the gnome-terminal tab I started sudo do-release-upgrade from may have been using the pts/1 pty.
root@abacus:~# ll /dev/pts/[0-5]
crw--w---- 1 lightdm tty 136, 0 Jul 17 16:45 /dev/pts/0
crw--w---- 1 root tty 136, 1 Jul 17 15:46 /dev/pts/1
crw--w---- 1 lightdm tty 136, 2 Jul 17 16:00 /dev/pts/2
crw--w---- 1 lightdm tty 136, 3 Jul 17 16:17 /dev/pts/3
crw--w---- 1 root tty 136, 5 Jul 17 15:22 /dev/pts/5 # my ssh session
Anyway, now that I have this reported, I'll see if I can get my laptop cleaned up and working :P I foresee some happy hours with aptitude. It was fairly far along in the upgrade, to the point where lsb_release -rd shows
Description: Ubuntu 14.04 LTS
Release: 14.04
for the record, since that's in the bug report guidelines.
Also, it's pretty cool that do-release-upgrade uses screen. I used ^s (xoff flow control), then ^space [ to pause and scroll back to look at stuff that caught my eye while scrolling past. I normally run everything from a screen session in a gnome-terminal tab managed by fluxbox, and have done so for about 10 years. So I'm very used to using screen. Never felt the need for a graphical shell, just a window manager to let me alt tab between my terminal and GUI programs.
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: ubuntu-
ProcVersionSign
Uname: Linux 3.8.0-28-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CrashDB: ubuntu
Date: Thu Jul 17 19:46:00 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2009-12-14 (1676 days ago)
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
PackageArchitec
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_CA.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-
Symptom: ubuntu-
UpgradeStatus: Upgraded to trusty on 2014-07-17 (0 days ago)
| Peter Cordes (peter-cordes) wrote | #1 |
| description: | updated |
| Peter Cordes (peter-cordes) wrote | #2 |
| summary: |
- weird problem running an editor inside do-release-upgrade's screen - session + ^x ^c while running an editor inside do-release-upgrade's screen session + disconnects part of the session |
| Peter Cordes (peter-cordes) wrote | #3 |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in ubuntu-release-upgrader (Ubuntu): | |
| status: | New → Confirmed |
| Joachim Durchholz (jo-durchholz) wrote | #5 |
| Joachim Durchholz (jo-durchholz) wrote | #6 |
| Joachim Durchholz (jo-durchholz) wrote | #7 |
| Joachim Durchholz (jo-durchholz) wrote | #8 |
| Nathan Collins (ntc2) wrote | #9 |
Oh! I apparently missed a line in the Screenlog when I was looking before. In the Screenlog that ubuntu-bug gathered up, right after the last of jed's stuff, there's a
=== Command terminated with signal 2 (Thu Jul 17 15:29:19 2014) ===
(at the very end, before the two restart attempts)
Which presumably came from the ^c as part of ^x ^c to exit jed. That was my other theory on what had happened. And that would explain how the trusty script got daemonized: its parent exitted, so it became a child of init, and no longer got sighup when my gnome-terminal died.
The "mainlog.txt" is useless, it's from the 2nd attempt to restart. If you want it, I can upload the files from /var/log/
-rw-r--r-- 1 root root 191K Jul 17 14:25 apt.log
-rw-r----- 1 root adm 945K Jul 17 15:46 apt-term.log
-rw-r--r-- 1 root root 141K Jul 17 14:33 history.log
-rw-r--r-- 1 root root 53K Jul 17 14:32 main.log
But your best bet is to try using ^c while in the shell spawned from an "examine the situation" conf files prompt, or an editor from that. (as I said, I used jed, in case it does something to the terminal that's slightly different from what emacs or vim would do). If that produces similar results, there's your culprit. I'm not sure where would be the best place to try to fix it, if that's the case. Maybe some kind of terminal settings? But how to do that without turning off ctrl interrupts ALL the time, not just when there's fullscreen text program running from a subshell.