LPIC-1 GNU and Unix Commands Practice Question
A company runs a legacy application on a Linux server. The application fails to start after a reboot, claiming a 'cannot open shared object file' error. The system administrator checks the library path and finds that the required library is present in /usr/local/lib but the application cannot find it. The administrator has verified that the library file exists and is readable. Which of the following is the most likely cause and solution?
⚠ Common exam trap
A common mix-up: candidates assume a library found in a standard-looking path like /usr/local/lib is automatically searched, but the dynamic linker only uses paths explicitly listed in /etc/ld.so.conf (or its included files) after running ldconfig.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The library path is not in /etc/ld.so.conf; run ldconfig after adding it.
The dynamic linker/loader (ld.so) uses the cache file /etc/ld.so.cache to resolve shared library dependencies at runtime. Although the library exists in /usr/local/lib, that path is not listed in /etc/ld.so.conf (or a file included by it), so the linker never scans it. Running ldconfig rebuilds the cache and makes the library discoverable, which resolves the 'cannot open shared object file' error.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The library has insufficient execute permissions; add execute bit.
Why it's wrong here
Readable libraries load without execute permission, so the execute bit is not the blocker; the loader searches only paths in /etc/ld.so.cache and DT_RUNPATH, and /usr/local/lib is absent unless added to /etc/ld.so.conf.d and refreshed with ldconfig. It tempts because permission faults do cause load failures, but the stem already confirms readability.
- ✗
The application is setuid root and the library path is ignored; use $LD_LIBRARY_PATH.
Why it's wrong here
Setuid binaries ignore LD_LIBRARY_PATH for security, so exporting it cannot help; the stem gives no indication the application is setuid. LD_LIBRARY_PATH is the correct remedy for a non-privileged process needing a library outside the cached search path, which is not the situation described.
- ✓
The library path is not in /etc/ld.so.conf; run ldconfig after adding it.
Why this is correct
The dynamic linker only searches directories listed in /etc/ld.so.conf and its includes, plus the cache built by ldconfig. Adding /usr/local/lib to that configuration and running ldconfig registers the library in the cache, letting the application resolve the shared object at startup.
- ✗
The library is compiled for a different architecture; recompile the library.
Why it's wrong here
A wrong-architecture library produces an ELF class or machine mismatch error, not 'cannot open shared object file'; the loader never reaches that check because it cannot locate the file. Recompiling is the right fix when ldd reports a binary-format mismatch, but the stem shows the library exists and is readable.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 402 original LPIC-1 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-1 practice question is part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LPIC-1 exam.