Java based destination drivers were introduced to syslog-ng last year. The syslog-ng application uses libjvm.so to embed a Java Virtual Machine inside syslog-ng. Java libraries tend to have a large binary footprint, even just the Java Runtime Environment (JRE) part of it. This is why Java is not bundled with syslog-ng: it would multiple the size of the syslog-ng package. Instead, syslog-ng uses the Java installed on the host.
Which Java to use?
- The syslog-ng Premium Edition (PE) supports only Oracle Java 1.7 or later. Oracle Java is used both for development and testing of syslog-ng Java destination drivers. Some users reported that OpenJDK 1.8 also works, but Balabit does not officially support it.
- For the syslog-ng Open Source Edition (OSE) any recent Java implementation should work. Linux distributions and FreeBSD include OpenJDK, where version 1.7 or newer should be OK. Oracle Java is also reported to work, but for packaging and testing OpenJDK is used as it is part of the different Linux distributions.
The libjvm.so problem
The Java module of syslog-ng is linked to libjvm.so, that is not included in the regular library directories (as multiple Java versions might be in use on the same system), so you will most likely receive the following error message when starting syslog-ng:
Error opening plugin module; module='mod-java', error='libjvm.so: cannot open shared object file: No such file or directory'
There are many ways to resolve / work around this problem. As a first step, you need find libjvm.so on your system. You can use the find command for this:
find /usr -name libjvm.so
Hint: while the exact path changes with the update of Java, there are often some simplified links available. For example on Fedora Linux: /usr/lib/jvm/java-1.8.0-openjdk-18.104.22.168-4.b16.fc22.x86_64/jre/lib/amd64/server/ is also available as /usr/lib/jvm/java/jre/lib/amd64/server The first link changes with each Java update, the second one stays stable between updates.
When using syslog-ng PE, generally you don’t see the above error message, as access to this library is configured automatically during installation. You will see it only if Java was not installed before you installed syslog-ng PE, or if you updated Java and the path to libjvm.so changed.
There are two ways to resolve this problem:
- Delete and reinstall syslog-ng PE, which will automatically find libjvm.so and configure syslog-ng PE to use it
- Edit or create the file containing the path to libjvm.so
In either case the file containing this information is /opt/syslog-ng/etc/environment The format of the file is:
Of course, you need to replace the path with the one available on your system. If your OS offers a simpler path that does not change with every Java update, use that instead.
In syslog-ng OSE there is no environment file, which makes things a bit more manual.
If you start syslog-ng from the command line, you need to configure the LD_LIBRARY_PATH environment variable, using the path name found previously. In case of the bash shell, use:
Of course, you need to replace the path with the one available on your system.
If you start syslog-ng with a startup script, there is no standard way to configure this environment variable.
- On FreeBSD you might add it to /etc/rc.conf or edit /usr/local/etc/rc.d/syslog-ng.
- On RPM based distributions /etc/sysconfig/syslog-ng is a suitable place.
- On Linux there is also a workaround, which might have some side effects, unless you are sure, that only one version of Java is installed on your system: You can add the directory name to /etc/ld.so.conf on a new line or in a new file with a .conf extension in the /etc/ld.so.conf.d/ directory.
- If you’re using puppet to configure your nodes, the puppetlabs-java module provides a fact which conveniently points to the location of libjvm.so: https://github.com/puppetlabs/puppetlabs-java