Hello.
We migrated RT 4.4.3 from CentOS 6.9 to Debian 10.
We have this cron job, which produces error instead of doing what it should do:
/opt/rt4/bin/rt-crontool --search RT::Search::FromSQL --search-arg "(Status != 'resolved') AND (Status != 'rejected') AND (Status != 'deleted') AND (Status != 'stalled') AND ((Due = '') OR (Due IS NULL)) AND (CF.ReminderDateTime > 'Jan 1, 1970') AND (CF.ReminderDateTime < 'now')" --condition RT::Condition::UntouchedInBusinessHours --condition-arg 27 --action RT::Action::SetStatus --action-arg "rejected"
It should find tickets, which have CF.ReminderDateTime set, then use the RT::Condition::UntouchedInBusinessHours to check if last transaction of the ticket is older than 27 business hours Instead it does nothing and produces the error:
[20759] [Tue Feb 4 07:17:10 2020] [warning]: Jan 1, 1970 is not a valid date string (/opt/rt4/bin/../lib/RT/SearchBuilder.pm:640)
We tried to decompose the job to find the cause of the error.
If we run a search in RT web interface using (Status != 'resolved') AND (Status != 'rejected') AND (Status != 'deleted') AND (Status != 'stalled') AND ((Due = '') OR (Due IS NULL)) AND (CF.ReminderDateTime > 'Jan 1, 1970') AND (CF.ReminderDateTime < 'now') conditions, we get 0 tickets.
So it seems to be an issue in conditions, because there clearly are tickets that meet the conditions.
In /opt/rt4/lib/RT/SearchBuilder.pm the “is not a valid date string” error is produced here:
my $date = RT::Date->new( $self->CurrentUser );
$date->Set( Format => 'unknown', Value => $value );
if ( $date->IsSet ) {
if (
$type eq 'Date'
# Heuristics to determine if a date, and not
# a datetime, was entered:
|| $value =~ /^\s*(?:today|tomorrow|yesterday)\s*$/i
|| ( $value !~ /midnight|\d+:\d+:\d+/i
&& $date->Time( Timezone => 'user' ) eq '00:00:00' )
)
{
$value = $date->Date( Timezone => 'user' );
} else {
$value = $date->DateTime;
}
} else {
$RT::Logger->warn("$value is not a valid date string");
}
So, we get this error if the $date->IsSet is false. We check the Set of RT::Date:
If $args->{‘Format’} is ‘unknown’, require Time::ParseDate and make it figure things out
OK, we try to see what happens when we use Time::ParseDate. We write a tiny script:
#!/usr/bin/perl
use Time::ParseDate;
$seconds = parsedate('Jan 1, 1970');
print "$seconds\n";
which produces “-10800” on the new environment (Debian 10 Buster) and “1577829600” on the old environment (CentOS 6.9).
At this point I realize, I’m no Perl developer, also no developer at all. And we try to use just common sense. Since the old environment is clearly wrong, we assume that issue is with the negative value of $seconds. We change the script to:
#!/usr/bin/perl
use Time::ParseDate;
$seconds = parsedate('Jan 4, 1970');
print "$seconds\n";
Now the result value is “248400”, which is not negative. We try using ‘Jan 4, 1970’ in the search in RT web interface: (Status != 'resolved') AND (Status != 'rejected') AND (Status != 'deleted') AND (Status != 'stalled') AND ((Due = '') OR (Due IS NULL)) AND (CF.ReminderDateTime > 'Jan 4, 1970') AND (CF.ReminderDateTime < 'now')
And yes, now we get a bunch of tickets that satisfy the conditions. OK, we change the date in the cron job:
/opt/rt4/bin/rt-crontool --search RT::Search::FromSQL --search-arg "(Status != 'resolved') AND (Status != 'rejected') AND (Status != 'deleted') AND (Status != 'stalled') AND ((Due = '') OR (Due IS NULL)) AND (CF.ReminderDateTime > 'Jan 1, 1970') AND (CF.ReminderDateTime < 'now')" --condition RT::Condition::UntouchedInBusinessHours --condition-arg 27 --action RT::Action::SetStatus --action-arg "rejected"
Now we get only [23786] [Tue Feb 4 07:56:43 2020] [notice]: Passed a unix time less than 0, forcing to 0: [-10800] (/opt/rt4/bin/../lib/RT/Date.pm:619)
We try to add the --verbose argument and then we get this:
3716:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3724:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3757:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3777:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3795:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3805:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3816:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
3821:
Processing without transaction, some conditions and actions may fail. Consider using --transaction argument
And now I’m completely lost. Please help:
- How to fix the environment to use the “Jan 1, 1970” date and not to get negative value?
- How to fix the “Processing without transaction, some conditions and actions may fail. Consider using --transaction argument” errors?