pt-kill --log-dsn may not work on Perl 5.8
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Toolkit moved to https://jira.percona.com/projects/PT |
Fix Released
|
High
|
Daniel Nichter |
Bug Description
lilith:~$ cat pt-kill.conf
defaults-
interval=1
busy-time=5
wait-after-kill=5
ignore-
match-info=
ignore-
daemonize
nostrip-comments
kill-query
log=/tmp/
log-dsn=
lilith:~$ cat /home/kolita/
[client]
user=msandbox
password=msandbox
host=127.0.0.1
port=25532
lilith:~$ cat /home/kolita/
[client]
user=msandbox
password=msandbox
host=127.0.0.1
port=5532
This works
/tmp/pt-kill --config /home/kolita/
This does not:
/tmp/pt-kill --config /home/kolita/
DBI connect(
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
53f5508840ab971
/tmp/pt-kill --config /home/kolita/
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.
Related branches
- Daniel Nichter: Approve
-
Diff: 686 lines (+379/-218)4 files modifiedbin/pt-kill (+14/-9)
lib/Sandbox.pm (+6/-0)
t/pt-kill/kill.t (+2/-209)
t/pt-kill/log_dsn.t (+357/-0)
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) |
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 |
Changed in percona-toolkit: | |
status: | In Progress → Fix Committed |
Changed in percona-toolkit: | |
status: | Fix Committed → Fix Released |
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.