[Nagiosplug-help] Problems with check_procs/pst3 on Solaris

[Andreas Ericsson]

Michael Beachler wrote:
> Hello,
> 
> I am currently having problems getting check_procs/pst3 to work properly 
> on both Solaris 7 and Solaris 8 boxes.
> 
> It appears that my box is running in 64-bit mode:
> 
> isainfo -v
> 64-bit sparcv9 applications
> 32-bit sparc applications
> 
> Here is the error that I receive:
> 
> check_procs -vvvv
> CMD: /opt/bcs/packages/nagios-2.3.1/libexec/pst3
> CRITICAL - Plugin timed out after 10 seconds
> 
> /opt/bcs/packages/nagios-2.3.1/libexec/pst3
> /opt/bcs/packages/nagios-2.3.1/libexec/pst3: /dev/ksyms is not a 32-bit 
> kernel namelist
> pst3: Failed to open kernel memory: Error 0
> 
> Thinking that this was a 32-bit vs. 64-bit problem I decided to play 
> around with pst3 a bit.  I downloaded the latest nagios-plugins-HEAD 
> tarball.  I located the pst3.c file within the plugins-root dir and 
> tried to compile it manually.
> 
> I am able to build the file manually by doing the following:
> 
> gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. 
> -I. -I.. -I.. -I../lib -I../intl -I../plugins -I/usr/lib 
> -I/usr/local/include  -I/usr/local/include  -g -O2 -c pst3.c
> 
> gcc -o pst3 pst3.o /usr/lib/libkvm.so.1
> 
> Now I have a pst3 executable and I can reproduce the error listed earlier:
> 
> bash-3.00# ./pst3
> ./pst3: /dev/ksyms is not a 32-bit kernel namelist
> pst3: Failed to open kernel memory: Error 0
> 
> I attempted to build a 64 bit executable via the following command:
> 
> gcc -m64 -o pst3 pst3.o /usr/lib/libkvm.so.1
> 
> I get this error:
> 
> /usr/lib/libkvm.so.1: could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
> 
> I "think" the reason I get this error is due to the shared object file 
> being a 32 bit file:
> 
> /usr/lib/libkvm.so.1:   ELF 32-bit MSB dynamic lib SPARC Version 1, 
> dynamically linked, not stripped
> 
> I found a 64 bit shared object for libkvm located in /usr/lib/sparcv9:
> 
> /usr/lib/sparcv9/libkvm.so:     ELF 64-bit MSB dynamic lib SPARCV9 
> Version 1, dynamically linked, not stripped
> 
> When I try to compile pst3 with the 64 bit shared object using this command:
> 
> gcc -m64 -o pst3 pst3.o /usr/lib/sparcv9/libkvm.so.1
> 
> I now get this error:
> 
> /opt/bcs/bin/ld: warning: sparc architecture of input file `pst3.o' is 
> incompatible with sparc:v9 output
> pst3.o:(.debug_aranges+0x10): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x10): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x14): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x280e): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x2812): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x2862): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x2866): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x28a0): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x28a4): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x28b3): relocation truncated to fit: R_SPARC_UA32 
> against `.text'
> pst3.o:(.debug_info+0x28b7): additional relocation overflows omitted 
> from the output
> collect2: ld returned 1 exit status
> 
> I don't have a whole lot of experience mucking with source code.  I did 
> notice however at the top of the pst3.c file that the author has tested 
> this in both 32-bit and 64-bit versions.
> 
> Anyone have any thoughts, suggestions, and/or ideas?
> 

Compiling is the act of transforming human-readable source-code to a 
binary object-code format. Linking is the act of coupling that 
object-code with the library functions it needs to make a complete 
executable of it. Might seem like nit-picking, but in this case the 
distinction is important.

You need to first *compile* the file in 64-bit mode, then *link* it in 
the same mode as you compiled it. Otherwise it will have all the wrong 
sizes of certain items (such as stack-pointers, variables, function 
pointers, data structures, ...) as can be seen by the output.

In short, the solution is to add -m64 to the string you pass to gcc when 
running it on the .c-file as well as when running it on the .o-file.

Totally untested, but should work gallantly.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231