Lua library issues preventing startup

Please include the following information with your help request:

  • Suricata version: 7.0.6
  • Operating system and/or Linux distribution: Alma 9.3
  • How you installed Suricata (from source, packages, something else): from source

I installed all dependencies and then compiled suricata with --enable-lua flag. When trying to start suricata however, I am getting error while loading shared libraries: liblua-5.1.so: cannot open shared object file: No such file or directory Output of suricata --build-info just shows suricata: error while loading shared libraries: liblua-5.1.so: cannot open shared object file: No such file or directory. I have lua, lua-devel, and lua-libs installed, all version 5.4, so I’m not sure how to proceed at this point…Thanks for any help!

Did you also compile Lua from source?

Otherwise having the packages compat-lua-libs and compat-lua-devel being should be all you need on AlmaLinux 9.

Ah yep, installing the compat-lua packages worked! Now I’m getting an error on the libhtp.so.2 library not being found =( Here’s what I have in /usr/local/lib/:

# ls -al /usr/local/lib
total 1960
drwxr-xr-x.  3 root root     115 Oct 16 10:25 .
drwxr-xr-x. 14 root root     157 Sep 26 14:37 ..
-rw-r--r--.  1 root root 1346168 Sep 26 14:37 libhtp.a
-rwxr-xr-x.  1 root root     928 Sep 26 14:37 libhtp.la
lrwxrwxrwx.  1 root root      15 Sep 26 14:37 libhtp.so -> libhtp.so.2.0.0
lrwxrwxrwx.  1 root root      15 Sep 26 14:37 libhtp.so.2 -> libhtp.so.2.0.0
-rwxr-xr-x.  1 root root  652568 Sep 26 14:37 libhtp.so.2.0.0
drwxr-xr-x.  2 root root      20 Sep 26 14:37 pkgconfig

sudo ldconfig /usr/local/lib

Hi, sorry for the delay in responding. I ran sudo ldconfig /usr/local/lib and restarted suricata, but now I am getting error while loading shared libraries: libevent_pthreads-2.0.so.5: cannot open shared object file: No such file. Not sure what’s going on with the shared libraries…

Have you updated your OS? From 9.3 to 9.4 or 9.5? If so you’ll likely have to rebuild Suricata so it links against the newer version of some libraries.

Nope, I’ve been on 9.3 the whole time…I did try rebuilding once already and that’s the build where I’m running into these issues. I guess I could try again…?

I took a closer look, just to make sure there was no breakage on our RPMs as well.

Somehow you have Suricata linked against libevent_pthreads-2.0.so.5, however, it looks like AlmaLinux 9.3 uses /lib64/libevent_pthreads-2.1.so.7 (to confirm on your system: ldconfig -p|grep libevent). Even AlmaLinux 9.0 used this version. So I’m not quite sure where that would be coming from for you.

Hmmmmm, would it be worth blowing away the current suricata install, upgrading Alma to 9.5 and rebuilding?

I don’t think that would solve the issue of where this library is coming from. But wouldn’t hurt either.

No need to remove the existing Suricata. Just do a fresh build. And make sure you are executing the Suricata you built and perhaps not some other old build.

Could also try the RPM: Guide: Getting Started on RHEL, CentOS and rebuild Linux Distributions

So just trying to install from RPM, without removing anything from the existing source build, yields this error:

> # yum install suricata
> Copr repo for suricata-7.0 owned by @oisf                                               5.5 kB/s | 1.8 kB     00:00
> Error:
>  Problem: cannot install the best candidate for the job
>   - nothing provides librte_eal.so.24()(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_eal.so.24(DPDK_24)(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_ethdev.so.24()(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_ethdev.so.24(DPDK_24)(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_log.so.24()(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_log.so.24(DPDK_24)(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_mbuf.so.24()(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_mbuf.so.24(DPDK_24)(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_mempool.so.24()(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
>   - nothing provides librte_mempool.so.24(DPDK_24)(64bit) needed by suricata-1:7.0.7-1.el9.x86_64 from copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0
> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

trying again with --skip-broken and it tells me it is already installed

> ========================================================================================================================
>  Package         Architecture  Version              Repository                                                     Size
> ========================================================================================================================
> Skipping packages with broken dependencies:
>  suricata        x86_64        1:7.0.7-1.el9        copr:copr.fedorainfracloud.org:group_oisf:suricata-7.0        3.3 M
> 
> Transaction Summary
> ========================================================================================================================
> Skip  1 Package
> 
> Nothing to do.
> Complete!

I’m not sure if that is referring to the source build, or a previous rpm install, which I think I did at one point and it didn’t work for me for some reason which is why ended up building from source. I think I should probably start fresh at this point–how can I ensure there are no artifacts left of any existing installs before I attempt again?

This is DPDK, it should be in the repos. You might have to upgrade to AlmaLinux 9.5, the lib-versions can change and our latest RPMs target the latest patch release.

But it does work for me, I’ve tested:

  • Fresh AlmaLinux 9.3 (and RockyLinux) in Docker and this RPM, dpdk is installed as part of the dependencies with DNF.
  • My personal deployment of Suricata uses this RPM on a full up to date AlmaLinux which is 9.5 at this time.

Are your repos pinned to 9.3 perhaps?

Ok, a quick test, if I pin my repos to AlmaLinux 9.3 the RPMs won’t work, they depend on a newer version of DPDK which is in 9.4 or 9.5…

This isn’t specific to DPDK or Suricata, it can happen with other packages as well, when found on COPR or EPEL. They are all built for the latest patch release.

Ok, got it. I will upgrade to 9.5 and see if I get different results. Thank you!

I upgraded Alma to 9.5 and installed suricata from rpm, which got rid of the shared libraries issue! Appreciate all your help @ish !

1 Like