This problem came up elsewhere, which lead to a discussion, and short story: the reporter is correct. On my Mac, for example, cron apparently pipes something to STDIN which is *not* a TTY, so this code
if ( !-t STDIN ) {
PTDEBUG && _d("STDIN is piped");
@ARGV = ('-');
}
makes the tool read from STDIN, but there's nothing there, so it exits immediately even though --daemonize was given. Reading from STDIN was so that we could test matching like "cat proclist | pt-kill ...". This is unreliable though because, for another example, on Ubuntu, cron also pipes something to STDIN but Perl says it *is* a TTY so the tool thinks it's running "normally" and therefore connects to MySQL as expected.
In short, testing STDIN and testing via STDIN are problematic so we're removing this and adding the option --test-matching FILES to make it explicit when we (or the user perhaps) wants to read FILES to test matching.
This problem came up elsewhere, which lead to a discussion, and short story: the reporter is correct. On my Mac, for example, cron apparently pipes something to STDIN which is *not* a TTY, so this code
if ( !-t STDIN ) {
PTDEBUG && _d("STDIN is piped");
@ARGV = ('-');
}
makes the tool read from STDIN, but there's nothing there, so it exits immediately even though --daemonize was given. Reading from STDIN was so that we could test matching like "cat proclist | pt-kill ...". This is unreliable though because, for another example, on Ubuntu, cron also pipes something to STDIN but Perl says it *is* a TTY so the tool thinks it's running "normally" and therefore connects to MySQL as expected.
In short, testing STDIN and testing via STDIN are problematic so we're removing this and adding the option --test-matching FILES to make it explicit when we (or the user perhaps) wants to read FILES to test matching.