# Product does not start after update on Linux (error: undefined symbol: JLI\_InitArgProcessing / JLI\_StringDup)

**URL:** <https://faq.inetsoftware.de/t/product-does-not-start-after-update-on-linux-error-undefined-symbol-jli-initargprocessing-jli-stringdup/250>\
**Category:** General\
**Tags:** java, update\
**Created:** [April 9, 2019, 5:43am UTC](https://faq.inetsoftware.de/t/product-does-not-start-after-update-on-linux-error-undefined-symbol-jli-initargprocessing-jli-stringdup/250 "2019-04-09T05:43:01Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![GerryWeissbach](https://faq.inetsoftware.de/user_avatar/faq.inetsoftware.de/gerryweissbach/32/90_2.png) [@GerryWeissbach](https://faq.inetsoftware.de/u/GerryWeissbach)\
**Post date:** [April 9, 2019, 5:43am UTC](https://faq.inetsoftware.de/t/product-does-not-start-after-update-on-linux-error-undefined-symbol-jli-initargprocessing-jli-stringdup/250/1 "2019-04-09T05:43:01Z")

</div>

When the product is updated, a new Java version will be included. We have noticed that sometimes the service does not start, especially when a Java VM has been installed previously.

The service that we install requires the java runtime executable (`runtime/bin/java`) to have certain traits to allow the service to run at port `80` and `443` - or any other port in the restricted services range below `1024`.

The service does therefore use the `setcap 'cap_net_bind_service+ep'` program to ensure these traits. In addition the the `LD_LIBRARY_PATH` has to be set so the `java` program can access `libjli.so`. This is done using a custom file entry in the path `/etc/ld.so.conf.d/` with a single line to the path of `libjli.so` and an update of the `ldconfig`.

The error `undefined symbol: JLI_InitArgProcessing` or `JLI_StringDup` can be mitigated by checking for previous java installations that might interfere. Check the `/etc/ld.so.conf.d/` path for a `*-java.conf` file and its contents. It is possible that this file is a leftover and can be moved aside.

Re-run `sudo ldconfig` to reload any changes made in the `/etc/ld.so.conf.d/` path and try to restart the service.

In short order:

- `ls /etc/ld.so.conf.d | grep java`
  - There should be only _one_ file with the name `<service>-java.conf`
  - You may check the content of the other files. If they do not match the installation folder of the service: move them aside

- `sudo ldconfig`