pt-kill --log-dsn may not work on Perl 5.8

Reported by markus_albe on 2013-08-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Toolkit
High
Daniel Nichter

Bug Description

lilith:~$ cat pt-kill.conf

defaults-file=/home/kolita/.my.cnf
interval=1
busy-time=5
wait-after-kill=5
ignore-info=(?i-smx:^insert|^update|^delete|^load)
match-info=(?i-xsm:select)
ignore-user=(?i-xsm:root)
daemonize
nostrip-comments
kill-query
log=/tmp/pt-kill.log
log-dsn=F=/home/kolita/pt-kill.cnf,h=127.0.0.1,P=25532,D=percona,t=kill_log

lilith:~$ cat /home/kolita/pt-kill.cnf
[client]
user=msandbox
password=msandbox
host=127.0.0.1
port=25532

lilith:~$ cat /home/kolita/.my.cnf
[client]
user=msandbox
password=msandbox
host=127.0.0.1
port=5532

This works
/tmp/pt-kill --config /home/kolita/pt-kill.conf h=127.0.0.1,P=5532

This does not:
/tmp/pt-kill --config /home/kolita/pt-kill.conf

DBI connect(';mysql_read_default_file=/home/kolita/.my.cnf;host=localhost;mysql_read_default_group=client','',...) failed: Access denied for user 'msandbox'@'localhost' (using password: YES) at /tmp/pt-kill line 2049

This is using patched version Daniel provided for customer (see attachments in 33351). Customer in that issue reported that this worked:

/tmp/pt-kill --version
pt-kill 2.2.3

md5sum /tmp/pt-kill
53f5508840ab97128d62fd19f94aeaad /tmp/pt-kill

/tmp/pt-kill --config /home/kolita/pt-kill.conf --log-dsn=F=/home/kolita/pt-kill.cnf,h=127.0.0.1,P=25532,D=percona,t=kill_log

But when he moved the log-dsn line to the .conf file, then it would stop working. For me log-dsn worked from the .conf file. Attaching output of PTDEBUG for failed run.

markus_albe (markus-albe) wrote :
description: updated
tags: added: i33351
summary: - pt-kill won't honor connection parameters provided in config files
+ ipt-kill won't honor connection parameters provided in config files
Changed in percona-toolkit:
milestone: none → 2.2.5
importance: Undecided → Medium
tags: added: config-file percona-33351 pt-kill
removed: i33351
summary: - ipt-kill won't honor connection parameters provided in config files
+ pt-kill doesn't honor connection parameters in config files
Changed in percona-toolkit:
status: New → Confirmed
Changed in percona-toolkit:
status: Confirmed → In Progress
importance: Medium → High
assignee: nobody → Daniel Nichter (daniel-nichter)

I can't reproduce this. From the debug here and my own, the correct DSN are being used. The access denied here doesn't seem to be because the wrong DSN info was or wasn't used; the MySQL privs are probably wrong.

Also, --log-dsn from a --config file works for me, but there was an odd line the code. It worked, but it shouldn't, so we were getting lucky that DBI was accepting the odd input as valid. Perhaps this was not the case on the customer's system, i.e. their DBI is more strict. I've written a test for this and fixed the odd line.

summary: - pt-kill doesn't honor connection parameters in config files
+ pt-kill --log-dsn may not work on Perl 5.8
tags: added: perl-5.8 perl-bug
Daniel Nichter (daniel-nichter) wrote :

I changed the title because the original bug did not exist, it turned out to be a feature limitation. --host default is "localhost", so when a DSN does not specify h, h=localhost is automatically used. There's no easy way around this except this one workaround: put "h=" in a --config file. Yes, nothing after the equals sign. This effectively unsets the --host default and makes it so that hosts have to specified somewhere for each DSN, where "somewhere" means a new --host default, or h in some config file or DSN.

There really was a bug that gave rise to the customer's issue in the first place: the rare Perl scope-closure bug where variables in inner scopes that are kept alive by a closure are lost later when the closure is called. This is fixed by moving the vars to an outer scope. So now all the --log-dsn related vars are in an outer scope.

There was also another problem: the retry code for doing --log-dsn query execution presumed that a reconnect would succeed, so it suppressed the error. So when the customer's reconnect failed, nothing was reported and there was no row in the log table either. Now reconnect errors are reported (though reconnection should cause an error in most cases).

Changed in percona-toolkit:
status: In Progress → Fix Committed
Changed in percona-toolkit:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers