Bug#799296: [debian-mysql] Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history

2015-09-18 Thread The Wanderer
On 2015-09-17 at 12:48, Clint Byrum wrote:

> Sorry that you had this happen. I wonder if the important commands
> were mysql grants for users?

It's not impossible that some of the oldest commands in the history
might have been such grants, but most of the history was more mundane
select and update queries - albeit ones with enough complexity to be a
pain to construct.

> More likely would be that perhaps you had the mysql client wrapped
> with a shell script that changed MYSQL_HISTFILE to something other
> than ~/.mysql_history ?

Not as far as I know. I haven't intentionally written any such wrapper;
as far as I know, what I was running was the version of /usr/bin/mysql
which is provided by mysql-client 5.5.44-0+deb8u1.

I also still have a backup copy of a (much) older ~/.mysql_history, from
before this database even existed, at a path and filename which seems to
indicate that I copied it from the name ~/.mysql_history. For whatever
that's worth.

> Thanks for reporting anyway, we'll try and figure this one out.

You're quite welcome. In the unlikely event that there's anything I can
do to help track this down, please don't hesitate to let me know.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history

2015-09-17 Thread The Wanderer
Package: mysql-client-5.6
Version: 5.6.25-4
Severity: minor

Dear Maintainer,

I habitually have an instance of mysql-client running, connected to a
particular database, with the somewhat-complex commands which I
regularly use with that database present in the mysql command history.

When I have upgraded mysql-client in the past, all I have needed to do
is to exit the old client instance after the upgrade and re-launch with
the new client, and everything has been seamless. In particular, the
command history from the previous client has still been present.

When I upgraded to 5.6, exited the 5.5 client, and re-launched with the
5.6 client, I discovered that my command history was empty.
Newly-entered commands made it into the new history just fine, but all
of the old ones were gone, apparently beyond recovery.

I expected that instead, my command history would be retained, as has
happened on every previous upgrade in what is substantially the same
scenario.

In this particular case, I was able to recover the main important
commands from where they were displayed in the terminal from the recent
5.5 session, but it is pure good fortune that all of the main important
commands had been used recently enough to still be visible in the
terminal's backscroll. If any had not been, I would be stuck with
reconstructing them from scratch.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mysql-client-5.6 depends on:
ii  debianutils4.5.1
ii  libaio10.3.110-1
ii  libc6  2.19-19
ii  libdbd-mysql-perl  4.028-2+b1
ii  libdbi-perl1.633-1
ii  libgcc11:5.2.1-17
ii  libstdc++6 5.2.1-17
ii  libterm-readkey-perl   2.33-1
ii  libwrap0   7.6.q-25
ii  mysql-client-core-5.6  5.6.25-4
ii  mysql-common   5.6.25-4
ii  perl   5.20.2-6
ii  zlib1g 1:1.2.8.dfsg-2+b1

mysql-client-5.6 recommends no packages.

mysql-client-5.6 suggests no packages.

-- debconf-show failed



signature.asc
Description: OpenPGP digital signature


Bug#799296: [debian-mysql] Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history

2015-09-17 Thread Clint Byrum
Excerpts from The Wanderer's message of 2015-09-17 09:18:49 -0700:
> Package: mysql-client-5.6
> Version: 5.6.25-4
> Severity: minor
> 
> Dear Maintainer,
> 
> I habitually have an instance of mysql-client running, connected to a
> particular database, with the somewhat-complex commands which I
> regularly use with that database present in the mysql command history.
> 
> When I have upgraded mysql-client in the past, all I have needed to do
> is to exit the old client instance after the upgrade and re-launch with
> the new client, and everything has been seamless. In particular, the
> command history from the previous client has still been present.
> 
> When I upgraded to 5.6, exited the 5.5 client, and re-launched with the
> 5.6 client, I discovered that my command history was empty.
> Newly-entered commands made it into the new history just fine, but all
> of the old ones were gone, apparently beyond recovery.
> 
> I expected that instead, my command history would be retained, as has
> happened on every previous upgrade in what is substantially the same
> scenario.
> 
> In this particular case, I was able to recover the main important
> commands from where they were displayed in the terminal from the recent
> 5.5 session, but it is pure good fortune that all of the main important
> commands had been used recently enough to still be visible in the
> terminal's backscroll. If any had not been, I would be stuck with
> reconstructing them from scratch.
> 

Sorry that you had this happen. I wonder if the important commands were
mysql grants for users? 5.6.8 added some ignoring functionality to try
and prevent cleartext logging to disk:

http://dev.mysql.com/doc/refman/5.6/en/mysql-logging.html

Perhaps there's also something that removes them from the existing file

More likely would be that perhaps you had the mysql client wrapped with
a shell script that changed MYSQL_HISTFILE to something other than
~/.mysql_history ?

Thanks for reporting anyway, we'll try and figure this one out.