After updating modules in cpan pnp4nagios/NPCD started logging the following in my syslog every time the script was called;
NPCD[19673]: ERROR: Executed command exits with return code '255'
NPCD[19673]: ERROR: Command line was '/etc/pnp4nagios/libexec/process_perfdata.pl -n --bulk /var/spool/icinga2/perfdata/host-perfdata.1524923929'
There didn't appear to be any loss in functionality or data and my graphs where populating as expected - but I was being spammed by this.
Running the script from the cli gave this result;
bash-4.1$ /etc/pnp4nagios/libexec/process_perfdata.pl -n --bulk /var/spool/icinga2/perfdata/host-perfdata.1524919009
tv_interval() 2nd argument should be an array reference at /etc/pnp4nagios/libexec/process_perfdata.pl line 218, <PDFILE> line 111
The only useful google result to that error points at the Time::HiRes module.
It appears that the current version of Time::HiRes was/is the issue. cpan offers Time-HiRes-1.9758 as an update but this appears to be the version causing the issue.
In order to stop the error I had to downgrade that module by doing the following;
make clean in the folder of the installed version (Mine was at .cpan/build/Time-HiRes-1.9758) then fetching the specific version from cpan;
cpan JHI/Time-HiRes-1.9721.tar.gz which installed the older (1.9721) version.
Restarted npcd and the errors where gone.
I'm not sure which version of Time-HiRes introduced this error/change in behaviour as I've not been through them and am not 100% certain where the issue may actually lay (npcd/Time-HiRes/somewhere else). Hopefully this points someone else in the right direction.
From ikegami's comment
"Even in version 1.9721, the second argument (if provided), must be an
array reference. It seems the only change in behaviour is the addition
of input validation. process_perfdata.pl is buggy, and newer
versions of Time::HiRes let you know it."
This is a problem even in the latest version of pnp4nagios.
If you need a quick workaround you can modify the pnp4nagios script process_perfdata.pl so that it does always pass an array reference, as follows (diff output):
sub main {
my $job = shift;
my $t0 = [gettimeofday];
- my $t1;
+ my #t1=();
+ my $t1=\#t1;
my $rt;
my $lines = 0;
# Gearman Worker
I've done this and it seems to work ok and remove the very frequent error message. I'll post back here if it seems to cause issues.
The problem is with the newest library Time:HiRes 1.9758 and the second value from tv_interval bounds. According to manual if ommited, the actual time is used - what is exactly what it does. So you need to apply this command to script process_perfdata.pl:
sed -s 's/tv_interval $t0, $t1/tv_interval $t0/g' -i process_perfdata.pl
After that everything will work as it should.
I experienced the problem with CentOS8 which is not providing older versions of HiRes library. Another symptom is that npcd cannot create .pnp-internal folder.
Related
We have a custom perl install (5.10.1) in /usr/share, and I tried to do a 'cpan -i' install of GeoIP2 here
After doing this, it seemed to install a lot of dependencies I couldn't keep track of, and since I've been getting an error
Subroutine IO::Socket::INET6::sockaddr_in6 redefined at /usr/share/perl5/Exporter.pm line 67
On most scripts that we run that uses a 'use' command. I've been trying to nail down which module eventually calls that, but not succeeded as yet.
After some research, one suggestion was to comment out the following lines of
/usr/share/perl5/IO/Socket/INET6.pm # (version 2.56, think latest is 2.72)
###commented out the following
###use Socket6 (
### qw(AI_PASSIVE inet_ntop inet_pton getaddrinfo
### sockaddr_in6 unpack_sockaddr_in6_all pack_sockaddr_in6_all)
###);
This has stopped the errors from appearing on various scripts. Does anyone know if this is safe to do (ie will it cause further problems later), and is there a better way to go (ie is it possible to just update that module, I'm guessing that would cause problems and break other stuff?). What would be the best method of getting the module updated correctly ?
This was a bug in IO::Socket::INET6 which was fixed in version 2.69 according to this bug report:
Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.14/Exporter.pm line 67.
...
Should be fixed in 2.69.
You can update the module using cpan with the command cpan IO::Socket::INET6 from the shell as root.
Easiest is just to stop using IO::Socket::INET6 at all. That was created a very long time ago, but a far better solution has been created using the core Socket module, being IO::Socket::IP. Furthermore, this latter module is now core also since the newly-released 5.20. it would be better to use that IO::Socket::IP as that is the new core-recommended way to achieve IPv4/IPv6 transparency from now on.
I'm currently trying to get this script to work:
https://github.com/mj41/auto-unrar/blob/master/bin/unrar2.pl
The only problem is that I get the following error:
Entering directory 'Series'
Entering directory 'Series/SerieName'
Entering directory 'Series/SerieName/Season2'
Entering directory 'Series/SerieName/Season2/SerieNameS02E21.720p.HDTV.X264-DIMENSION'
Entering directory 'Series/SerieName/Season2/SerieNameS02E21.720p.HDTV.X264-DIMENSION/Sample'
Can't call method "List" on an undefined value at unrar2.pl line 973.
This line is rar_obj->List();
$rar_conf{'-verbose'} = $rar_ver if $rar_ver;
my $rar_obj = Archive::Rar->new( %rar_conf );
$rar_obj->List();
my #files_extracted = $rar_obj->GetBareList();
This is an old script, 3-4 years old and I changed a little like SHA1 to SHA and use Filesys::DfPortable; to Df
Does anyone know how I can fix this error :)?
EDIT:
I contacted the developer and he told me I needed to install a program that can handle rar commands. So how would I do that. I can't seem to be able to install unrar.
EDIT2:
What my problem is now, 2 of the 3 unrar packages aren't in my architecture, armhf.
To install the script yourself::::::::::::
https://github.com/jorricks/UNRAR
You need to pass the -archive parameter into the call to new() otherwise how will $rar_obj know which file it is supposed to be looking at?
I can't seem to be able to install unrar
That's not a particular good explanation of your problem. What did you try? What unexpected behaviour did you see?
From the tags on your question, it looks like you're running Debian. What do you see if you run sudo apt-get install unrar?
Update: My first comment was based on the code extract that you showed us. Looking at the full program code, I can see that %rar_conf has other values set in it (including the -archive option) before the section of code you gave us.
Looking at the source of the Archive::Rar module, it seems to assume that the program to use for dealing with the archives is called rar. So 7-Zip is not going to work.
I added a script to the package maker - under Distribution->Requirements. The problem I have is the script result is always false (at least from the installer prospective). I have simplified my script below. Even this script fails? I've executed this command from terminal and the return value is zero as expected.
I'm using verion 3.04 of package maker.
#!/usr/bin/perl -w
use strict;
exit 0;
I've tried returning 1 as well but the result is always the same.
Anyone have success with a requirement script and package maker?
Is it necessary to use a perl script?
If not, you can use a shell script. I use it and it works.
#!/bin/sh
#do your stuff
exit 0
You can get some more info at Scripting in Packagemaker
Are you sure the script doesn't get evaluated? I also added a script to the requirements list and got weird results. What I found in another article on StackOverflow was, that the return value is just interpreted in an unexpected way. Here's the article:
PackageMaker "Result of Script" requirement never passes
This solved the problem for me. Hope it helps!
I've inherited some Perl code that runs on a Linux server just fine. I'm in the process of getting it to run on Windows XP, ActiveState Perl 5.16.2, and a BitNami WAMP stack. (Note: this setup is already running my Perl .cgi programs so this is a working setup.)
Anyway the "main" Perl program--let's call it main.cgi--has this statement:
require("extra/stuff_1.cgi");
When main.cgi runs, an error occurs:
C:/BitNami/apache2/cgi-bin/extra/stuff_1.cgi did not return a true value at C:/BitNami/apache2/cgi-bin/main.cgi line XX.
Now here's what is weird: stuff_1.cgi ends with 1; (i.e., it is the last line in the file)!
I've even commented out the code in the functions within stuff_1.cgi -- which are mostly functions with Here Documents, e.g.
sub func {
return <<EOF;
...
EOF
}
making it contain just
sub func {
#
#return <<EOF;
#...
#EOF
}
etc.
and yet the "did not return a true value" still occurs!
However if I delete all the code so stuff_1.cgi contains
1;
the error goes away (as it should).
stuff_1.cgi passes perl -c, even with use strict and use warnings
ETA: If I copy the contents of stuff_1.cgi and paste it into main.cgi (replacing the require statement), the code works just fine.
I've never seen anything like this before; what could possibly be the cause?
Why is the debugger not working (ActiveState or Strawberry Perl under Windows)?
Why is the debugger not working [ActiveState or Strawberry Perl under Windows]?
A recent release of PathTools (part of Perl distribution, file Cwd.pm) unfortunately contains a bug which breaks EPIC's debugger frontend. The specific symptom is the error message "perl5db.pl did not return a true value." - to see this message, you should enable the "debugger console" in EPIC Preferences. Furthermore, if you have this problem, debugging doesn't work at all. To fix it, you must edit Cwd.pm of your Perl distribution and remove the offending "eval" keyword from one line, as described in this bug report. DO NOT attempt to fix it by adding Perl's "lib" directory to your project's include path, as this will cause all breakpoints to be ignored!
Perhaps what I've encountered is a defect in ActiveState's version of Perl.
Anyway--after spending way too much time on this--the only way I could get it to work is by replacing
require 'extra\stuff_1.cgi';
with
eval { require 'extra\stuff_1.cgi' };
I dislike having to do this but it's time to move on!
I have a Perl program written by someone else. When I run it, it silently exits without writing anything to the logfile. Is there a way I can run this Perl program step by step, line by line by the interpreter and thus get to see where it terminates?
Yes, there is the Perl debugger which you can invoke with perl -d.
Documentation can be found in perldoc perldebug and perldoc perldebtut.
Probably the most useful commands would be:
s - step into current line.
n - step over current line.
r - step out of current function.
p <expr> - print the expression.
b <line|subnm> - sets a breakpoint
T - produce a stack trace.
c [<line|subnm>] - continue running with optional one-time breakpoint.
h - help (for other commands).
Hachi has the answer. Use the Perl debugger by running perl with the -d flag. For information on how to use the debugger past starting it, see the Perl Debugging Tutorial.
There is a Perl module called "ptkdb" which is a standalone Perl interactive debugger. It works using the Tcl/Tk GUI, so you'll need that, too.
Depending on your OS you'll need to add some required modules.
Invoke it using
perl -d:ptkdb <your script>
If running some Unix/Linux system, you also need an X server.
There are two ways. The first is the one which Hachi and llioin already gave which is using the command-line switch "-d".
Or use an IDE. I am tried and used Komodo IDE which works like charm.