Comment 3 for bug 1343737

killing the running dpkg and then trusty processes changed the timestamp on the files in /var/log/dist-upgrade/20140717-1529/apt-term.log and history.log, so they were indeed still open.

 dpkg --configure -a finished ok, so looks like my laptop will be fine. yay for robust package systems.

 The end of apt-term.log is
.... bunch of colored text that's missing jed's cursor-movement stuff when I view it with less ...

                                                               ^M***Fatal Error: Killed by signal 15.

jed version: 0.99.19/Unix
 Compiled with GNU C 4.6
S-Lang version: 2.2.4

jed compile-time options:
 +LINE_ATTRIBUTES +BUFFER_LOCAL_VARS +SAVE_NARROW +TTY_MENUS
 +EMACS_LOCKING +MULTICLICK +SUBPROCESSES +DFA_SYNTAX +ABBREVS
 +COLOR_COLUMNS +LINE_MARKS +GPM_MOUSE +IMPORT
CBuf: 0x7f9c5c5f4910, CLine: 0x7f9c5c590630, Point 0
CLine: data: 0x7f9c5c5cc7f0, len = 18, next: 0x7f9c5c590650, prev (nil)
Max_LineNum: 39, LineNum: 1
JWindow: 0x7f9c5c5ca9f0, top: 1, rows: 40, buffer: 0x7f9c5c5f4910
root@abacus:/etc/etckeeper# exit

Configuration file '/etc/etckeeper/etckeeper.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
      D : show the differences between the versions
      Z : start a shell to examine the situation
 The default action is to keep your current version.
*** etckeeper.conf (Y/I/N/O/D/Z) [default=N] ? Log ended: 2014-07-17 23:51:45
-----

All that's new is the Log ended: stuff. The rest was all there even before I tried to start firefox and ended up exitting X. So it had re-prompted for what to do about the conffile even after jed got a sigterm (which I sent with kill from another shell). The "exit" on the bash prompt was printed by bash when I sent it a sigterm.

  (btw, stop lightdm finally fixed the intermittent pauses that were affecting even the ssh session, it must have been starting new X servers every couple minutes. Totally unconnected to this bug, a symptom of where the upgrade got stuck. Just feeling chatty I guess.)

 Anyway, note that apt-term.log did NOT include the signal 2 (sigint), so it wasn't a process running in that terminal that got the sigint from the ^c, it was somewhere above the parent of the trusty upgrade script, I guess. I hadn't looked at screenlog, only apt-term.log, until I was done typing the original bug report.

 I changed the bug title to match the theory that it was the ^c that caused the problem, not a screen escape sequence.

 Also meant to mention that this is slightly similar to
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1302218
where the submitter tried to start a subshell from inside the terminal widget in the gui release-upgrader.