Created attachment 647667 [details] error_log Description of problem: Message "/opt/rh/ruby193/root/usr/bin/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory" is seen in /var/log/httpd/error_log Version-Release number of selected component (if applicable): On devenv_2497 How reproducible: Always Steps to Reproduce: 1. ssh into instance 2. vi /var/log/httpd/error_log Actual results: "/opt/rh/ruby193/root/usr/bin/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory" is shown in error_log Expected results: Should not have above message. Additional info: error_log is attached.
This is happening because httpd process doesn't have LD_LIBRARY_PATH set correctly to include /opt/rh/ruby193/root/usr/lib64. I believe this is coming from /etc/httpd/conf.d/ruby193-passenger.conf, where Passenger is getting loaded. Injecting the following line into /etc/init.d/httpd eradicates the message: LD_LIBRARY_PATH=/opt/rh/ruby193/root/usr/lib64:$LD_LIBRARY_PATH It is not clear to me, though, if this module should be loaded by the node itself. If it should, I would think that we have a bigger than a simple error message. If it should not, maybe we should remove ruby193-passenger.conf entirely. I'm re-assigning to jhonce for re-assessment.
Something is wrong with the packaging. Either the module is in the wrong place, or something is wrong with it's configuration.
The error in the logs is what you get when you try to run the ruby193 ruby without being in the scl enviroment. # /opt/rh/ruby193/root/usr/bin/ruby /opt/rh/ruby193/root/usr/bin/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory But, the module loads and appears to work correctly. I've checked it on nodes where there is no ruby 1.8 version of passenger. So, this is a low priority. That being said, it appears we need to work with the SCL developers to figure out the correct way to get SCL modules to load in normal httpd.
Further investigation has revealed that it's a problem with how Passenger 3.0.21 deals with starting native modules. This process has been completely re-written in Passenger 4.0.x, and this error shouldn't show up when we switch to that version. For now, this is not a bug that affects performance or features. It just shows an alarming line in the logs.