Unable to start packetbeat


(Nemo) #1

I am unable to start packetbeat and getting below error

/packetbeat: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory

but I am using different version of libpcap.so. So how can I force packetbeat to pickup my libpcap file?


(Tudor Golubenco) #2

Hi, what OS are you using? The current binaries depend on the shared libpcap library, so I'm afraid you need that libpcap version. The good news is that we're working on a new build system that will statically compile libpcap in the binary, so this will no longer be an issue with beta3.

You have two options:

  • compile it yourself against your libpcap version by following the steps here

  • I can send you a static binary built with the new system if you are willing to test it before it's released.

Let me know.


(Nemo) #3

Hi Tudor,
Thank you for your reply.
I think second option looks great for me. Can you please share me the static binary? Looking forward for your reply.


(Tudor Golubenco) #4

You can find the statically compiled binary here. It's really just the binary which you can execute directly, not in a packaged form yet. But you can use the configuration file and the template from the regular zip. Let me know if you have issues with it.


(Nemo) #5

Thank you very much. I will keep you posted on my status :smile:


(Putztzu) #6

I'm also seeing this odd error... Why would anything complain about loading shared libraries nowadays? AFAIK the distinction between a "Shared Library" and normal "library" was deprecated more than 5 yrs ago, so today there is no need for things like specifying a "Shared Library Path" In any case, this error results from trying to run packetbeat from an extracted TAR. Was surprised that the TAR contains only a couple binaries, a YML file and a JSON file.

In any case, on my system the following is installed from the current libpcap stable package (omitting licenses and other text files)

/usr/lib64/libpcap.so.1
/usr/lib64/libpcap.so.1.6.2
/usr/share/doc/packages/libpcap1
/usr/share/man/man7/pcap-filter.7.gz
/usr/share/man/man7/pcap-linktype.7.gz
/usr/share/man/man7/pcap-tstamp.7.gz

Also, I downloaded your compiled binary but am perplexed about your binary's name. I doubt "packetbeat-linux-amd64" is the proper name but tried it anyway after also changing the name to "libpcap.so.0.8" and placing that file in the same folder as the packetbeat executable. Neither works and continues to fail with the same error.


(Ricardo L) #7

Hi Tudor,

Could you upload that statically compiled binary again?
I'm POC'ing beats on our elastic stack and I can't 'mess around' with the current libpcap version under /lib64

Would be really thankful for that!
cheers


(Tudor Golubenco) #8

Sure, in the meantime we have OS packages (that's why the link is broken). Here is the DEB amd64 and the RPM amd64. If you prefer some other package, let me know (or you can get the listing here). Note that these links might also go 404 in a few days because we're actively changing the way we're handling nightlies.

Also note that this is unreleased software :-). Let us know if you hit any issues.


(Ricardo L) #9

Thanks a lot, but I need the ELF 64-bit executable with libpcap statically compiled.
This is for a Red Hat Enterprise Linux Server release 5.7 (Tikanga)

Current packetbeat binary downloaded from elasticsearch:

POC:~/elk/elasticsearch-1.4.4/packetbeat-1.0.0~Beta1> file packetbeat
packetbeat: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.18, dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped*

POC_:~/elk/elasticsearch-1.4.4/packetbeat-1.0.0~Beta1> ldd packetbeat
linux-vdso.so.1 => (0x00007fff73dfd000)
libpcap.so.0.8 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b84200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003b83600000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b83200000)

POC_:~/elk/elasticsearch-1.4.4/packetbeat-1.0.0~Beta1> ./packetbeat
./packetbeat: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory

Sorry for the trouble!


(Tudor Golubenco) #10

Try this one. That's a full statically linked binary, let us know if it works or not, pls.


(Ricardo L) #11

It works. I already see a new index called '.packetbeat-topology' in Marvel.

./packetbeat -c packetbeat.yml
main.go:158: CRIT Initializing sniffer failed: Error creating sniffer: any: You don't have permission to capture on that device (socket: Operation not permitted)

I have to struggle further now because of the lack of permissions to sniff traffic.
Using 'af_packet' doesn't seem to help either so I'll have to resort to the sysadmins now.

# Select the network interfaces to sniff the data. You can use the "any"
# keyword to sniff on all connected interfaces.
interfaces:
# device: any
device: bond0
type: af_packet
buffer_size_mb: 100

Thanks for the assistance. I'll follow up once I get the permissions issue sorted...


(Tudor Golubenco) #12

You'll need to either start the process as root or set the packet capture capability on the binary, see this thread.


#13

Hello tudor!

I have also several problems to make packetbeats run on my Linux system:
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.0 (Maipo)

First I started with packetbeat-1.0.0-beta2-x86_64.tar.gz but it refused to run with error:
./packetbeat: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory

But libpcap is installed:
yum list|grep libpcap
libpcap.x86_64 14:1.5.3-4.el7_1.2 @rhel-x86_64-server-7

The I tried with packetbeat-1.0.0-nightly.150826174057-x86_64.tar.gz as recommended. I also set the CAP_NET_RAW capability: sudo setcap cap_net_raw=ep /usr/bin/packetbeat

packetbeats starts without problems if elasticsearch output isn't used. E.g. file output works!

But when I use elasticsearch output (E.g. the default packetbeat.yml file) the following error occurs:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x63 pc=0x7fa585d2357c]

runtime stack:
runtime.gothrow(0xa7b3d0, 0x2a)
/usr/local/go/src/runtime/panic.go:503 +0x8e
runtime.sigpanic()
/usr/local/go/src/runtime/sigpanic_unix.go:14 +0x5e

goroutine 12 [syscall, locked to thread]:
runtime.cgocall_errno(0x401ab0, 0xc20801acd0, 0x0)
/usr/local/go/src/runtime/cgocall.go:130 +0xf5 fp=0xc20801ac90 sp=0xc20801ac68
net._C2func_getaddrinfo(0x7fa5800008c0, 0x0, 0xc20801adc8, 0xc20801ad18, 0xc200000000, 0x0, 0x0)
/usr/local/go/src/net/:26 +0x55 fp=0xc20801acd0 sp=0xc20801ac90
net.cgoLookupIPCNAME(0xc208040f07, 0x9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc208050400)
/usr/local/go/src/net/cgo_unix.go:96 +0x1c5 fp=0xc20801ae00 sp=0xc20801acd0
net.cgoLookupIP(0xc208040f07, 0x9, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc2090d7b37)
/usr/local/go/src/net/cgo_unix.go:148 +0x65 fp=0xc20801ae58 sp=0xc20801ae00
net.lookupIP(0xc208040f07, 0x9, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/net/lookup_unix.go:64 +0x5f fp=0xc20801aea0 sp=0xc20801ae58
net.func·026(0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/net/lookup.go:79 +0x55 fp=0xc20801af08 sp=0xc20801aea0
net.(*singleflight).doCall(0xe99970, 0xc2091343c0, 0xc208040f07, 0x9, 0xc209115cf0)
/usr/local/go/src/net/singleflight.go:91 +0x2f fp=0xc20801afb8 sp=0xc20801af08
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20801afc0 sp=0xc20801afb8
created by net.(*singleflight).DoChan
/usr/local/go/src/net/singleflight.go:84 +0x42b
...

I truncated the output due to restriction to 5000 characters.

Could you please check?

Thank you in advance!


(Tudor Golubenco) #14

@MartinG we've just released beta3. Can you try with it, please? https://www.elastic.co/downloads/beats/packetbeat


#15

Hello Todur,

Beta3 works as expected. Thanks a lot!

I have an idea for an improvement: is it possible to provide more detailed Information regading the response time? Commercial tools like Oracle Real User Experience Insight are able to differentiate between server, client and network time.

Greetings,

Martin


(Ricardo L) #16

Just as a follow up: Everything is working fine once the capabilities are set up.

Thanks once more.


(system) #17