When I run sudo bpftool prog show I get the following output
39: socket_filter name bpfprog1 tag e29cda32ba011d7f gpl
loaded_at 2019-09-08T14:21:57+0200 uid 1000
xlated 248B jited 169B memlock 4096B map_ids 30
but If I try to get the program jitted output with the following command
sudo bpftool prog dump jited tag e29cda32ba011d7f
I get an error message, as reported below:
Error: can't get prog info (3): Bad address
QUESTION: what am I doing wrong? XD
You most certainly use a bpftool version compiled from Linux 4.20 or older, and hit a bug that was fixed in version 5.0. Update bpftool, and dumping programs by tags should work again.
As a side note, I usually use program IDs or pinned path, as I find it more useful to retrieve the program I want. Depending on your use case, tags might make sense, especially if you often load the same programs without changes (so you would be sure to keep the same tags) and do not have them pinned.
Related
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.
I am trying to use Python's Popen() to retrieve graph data from a multiple rrd files. Due to complexity of app where the following piece of code is utilised, I rely on rrdtool graph parameter -Z for handling missing files for me:
#!/bin/python3
import subprocess
cmd = '/opt/rrdtool/bin/rrdtool graph - -a JSONTIME -Z --width 924 --start 1486428000 --end 1486471200 DEF:foo1=ch1.rrd:flows:MAX DEF:foo2=ch2.rrd:flows:MAX AREA:foo1#000:"ch1" AREA:foo2#606060:"ch2":STACK'
path = '/data/live/pokus/rrd/channels/'
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, cwd=path, shell=True)
p.wait()
if p.returncode is not 0:
print("Error")
else:
print(p.stdout.read().decode(encoding="utf-8"))
Following code works as expected when both files ch1.rrd and ch2.rrd are present. When one of them is missing, whole thing hangs indefinitely until I kill the rrdtool process manually from htop. Then python detects nonzero return code and reports error.
Using shell=False and shlex.split() on cmd does not help.
When I execute the same command from bash, even with the missing files rrdtool does the job as expected.
Unfortunately I can't use rrdtool bindings for python and also I am stuck on python 3.4.5. rrdtool version is 1.6.0.
I am glab for any idea how to overcome this. I would prefer solution that does not include testing whether files exist from python and keeps the -Z parameter in rrdtool command. Also using timeout on p.wait() isn't a viable solution.
Thanks in advance
Ok, I found the solution.
The reason why Python (namely p.wait) hanged was because rrdtool did not know the minimum step size (parameter -S) resulting in step size of two seconds. This way, output of the rrdtool was able to fill the OS buffers and that deadlocked p.wait. According to Python docs, Popen.communicate should be a way to go.
I'm trying to write a program to automate getting the call stack from crash dumps. It runs cdb.exe:
cdb.exe -i "{binaries path}" -y "{binaries path}" -srcpath "{source files path}" -z "{dmp file path}" -lines
I then feed some commands to CDB's standard input:
.symfix+ c:\\symcache
.ecxr
k
q
For many dumps this succeeds in printing the call stack, however some dumps do not work. The dumps that don't work output this error:
Unable to load image C:\Windows\System32\igdumd32.dll, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for igdumd32.dll
However, Visual studio is able to figure out the call stack just fine. In the Visual Studio call stack, igdumd32.dll is at the bottom of the stack:
igdumd32.dll!0c70c570()
[Frames below may be incorrect and/or missing, no symbols loaded for igdumd32.dll]
I'm not sure if the symbol not loading is the problem or not, but I can't figure out why CDB can't get the call stack while Visual Studio can.
"Frames below may be incorrect and/or missing"
Sometimes this means what it says, annoyingly. I've no idea what VS does to get around it. So far the best I have for cdb is to, instead of k, run kd (the cdb command, not kd the kernel debugger program!) to get the raw stack data, then discard the junk lines between the useful ones.
You'll probably want to supply a number of lines (in hex) after kd to get enough output to contain the whole call stack.
e.g.
kd 200
Oh, this doesn't work for dumps generated from 64-bit processes because kd uses the wrong word size (afaict this is a bug). I'm currently looking for a way to work around this cleanly. For one thread you should be OK with something like:
dps #esp L200
This uses the esp register to access the stack, which is not portable but works for me. You may need a different register.
I want to profile my Perl code by using Devel::DProf.
when I am running the profiler like
perl5.8 -d:DProf abc.pl # default version of Perl in my PC (Solaris) is 5.003
then it produces the tmon.out file in the current directory, but when I run
dprofpp
then it is not undertanding the command and giving error like command not found.
I know Devel::DProf - a DEPRECATED Perl code profiler, and should use Devel::NYTProf but just want to know why it is giving such an error, may be I am missing something.
How can I solve this?
Find out where you installed dprofpp and ensure that the directory is in your PATH, or call it with the full path.
While working with Valgrind tool, i need to log the details produced by valgrind tool. How can I accomplish that? I tried something like,
valgrind a.out | test
and
valgrind a.out > test
It gave just the program's output and not the valgrind memory error,leak information. Even i am getting like this if the program requires no user interaction (i.e. giving input). If the program need user input even that thing itself won't work.
How can I do this?
valgrind --log-file="filename"
By default, Valgrind writes its output to stderr. So you need to do something like:
valgrind a.out > log.txt 2>&1
Alternatively, you can tell Valgrind to write somewhere else; see http://valgrind.org/docs/manual/manual-core.html#manual-core.comment (but I've never tried this).
You can also set the options --log-fd if you just want to read your logs with a less.
For example :
valgrind --log-fd=1 ls | less
In addition to the other answers (particularly by Lekakis), some string replacements can also be used in the option --log-file= as elaborated in the Valgrind's user manual.
Four replacements were available at the time of writing:
%p: Prints the current process ID
valgrind --log-file="myFile-%p.dat" <application-name>
%n: Prints file sequence number unique for the current process
valgrind --log-file="myFile-%p-%n.dat" <application-name>
%q{ENV}: Prints contents of the environment variable ENV
valgrind --log-file="myFile-%q{HOME}.dat" <application-name>
%%: Prints %
valgrind --log-file="myFile-%%.dat" <application-name>