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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1343737
Title:
^x ^c while running an editor inside do-release-upgrade's screen
session disconnects part of the session
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1343737/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
