I'm at my wits' end on this. I have 2 RH7 boxes that I just installed httpd24 (v2.4.34) on. They were running httpd (v2.4.6) without any connection problems. Now when I try and run Perl scripts from the browser, they fail with...
install_driver(Informix) failed: Can't load '/usr/local/lib64/perl5/auto/DBD/Informix/Informix.so' for module DBD::Informix: libifsql.so: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 190.
at (eval 5) line 3.
Compilation failed in require at (eval 5) line 3.
Perhaps a required shared library or dll isn't installed where expected
at /var/www/html/app/cgi-bin/test_informix_odbc.cgi line 35.
But when I run the same script from the command line, as 'apache', it runs just fine. All the ENV vars are set correctly.
Anyone run into anything similar before?
It would no longer use the LD_LIBRARY_PATH environment variable I was setting in httpd.conf.
Services are started in a fresh environment without any influence of user's environment (like environment variable values). As a consequence, information of all enabled collections will be lost during service start up.
Newer versions of httpd have stopped bringing the user environment in when the service is started. I found this little blurb in /opt/rh/httpd24/service-environment.
grep -r "LD_LIBRARY_PATH" /opt/rh/httpd24/
/opt/rh/httpd24/enable:export LD_LIBRARY_PATH=/opt/rh/httpd24/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
I prepended the standard informix paths in /opt/rh/httpd24/enable.
export LD_LIBRARY_PATH=/opt/IBM/informix/lib:/opt/IBM/informix/lib/esql:/opt/rh/httpd24/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
And everything is back to normal. Woohoo!
I have a project in Java and the test scripts are written in robot.
I want to run my test scripts on the server where I have a WAR file, (after building), of my project. When I am running my test scripts on the local system it working, but When I run my test scripts on server, some tests are getting passed and some are getting failed. My server is Ubuntu 14.04.
I am using the following command to run test scripts on server:
pybot -v env:dev /var/lib/jenkins/jobs/AnATest/tests/
where env:dev is just environment name and /var/lib/jenkins/jobs/AnATest/tests/
is my directory where all my robot tests files are residing.
Please tell me, if more information is required.
It sounds like you simply have a different version of a library on your server than on your local machine. The one on the server has a get request keyword that doesn't take the same arguments as the one on your local machine.
I have properly configured the Seleniumhq plugin into Jenkins. I've also tried to run it in my local Jenkins and it worked. The problems I encounter are as follows:
suiteFile directory reads from C drive ONLY. Example, C:\TestSelenium\testSuite.html
When I try to specify the absolute path to my test suite (workspace), I get the error
The suiteFile is not a file or an url ! Check your build configuration.
Same thing happens with resultFile.
When I add post-build action "Publish Selenium Report," I'm getting an error because the newly created resultFile is saved into C:\TestResult\result.html and not in the workspace.
I am trying to run Apache Tomcat 8.0.21 in debug mode.
When I give the command
sh catalina.sh jpda start
it gives this error.
error message
ERROR: Cannot load this JVM TI agent twice, check your java command
line for duplicate jdwp options. Error occurred during initialization
of VM agent library failed to init: jdwp
Can anyone help ?
Either
unset CATALINA_OPTS
unset JPDA_ADDRESS
unset JPDA_OPTS
unset JPDA_TRANSPORT
catalina.sh jpda start
Or
# in .bashrc, .profile etc.
export CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 -Djava.security.egd=file:/dev/urandom -Denv=dev -Xms1024M -Xmx2048M -XX:PermSize=256M -XX:MaxPermSize=768m"
# At your shell prompt
./startup.sh
Explanation
As Arnab said in the comments, if your shell configuration includes environment variables mentioning jdpw (such as CATALINA_OPTS, JDPA_ADDRESS, JPDA_OPTS), just launch using ./startup.sh as if you were not trying to do remote debugging and the script will pick up the jdpw option from your environment variables.
The launch option syntax catalina.sh jpda start should only be used if you don't have any environment variables that already specified a remote debug port. It's meant to be convenient but if you've previously configured your shell to support java remote debugging you're probably mixing the two alternative approaches.
You can just add env variable and run the tomcat as usual
Debug port is 8000 in this case
export CATALINA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n"
Then run the tomcat
sh ./catalina.sh start
This happened to me with Eclipse when I tried to add the debugging parameters (-Xdebug -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=y) so I could suspend Tomcat on start. Unfortunately I then launched my Tomcat (within Eclipse) using the Debug button.
Why this is a problem
When you are launching Tomcat in Debug mode Eclipse itself inserts the debug parameters. When you have your own debug parameters in the launch configuration you are indeed passing them twice.
So if you need to launch Tomcat from within Eclipse and suspend it on start (so you can connect with debugger) you need to:
- add the debugging parameters to the "Arguments -> VM arguments" box of your launch config,
- and then Run this config, not Debug.
This way only the debugging parameters from your launch config are added.
There is alternative approach, recommended in 'catalina.sh':
"Do not set the variables in this script. Instead put them into a script
setenv.sh in CATALINA_BASE/bin to keep your customizations separate."
For Windows, the file name with environment variables will be 'setenv.bat'.
Thank you mr Dimitar II
Verified this works perfectly and is consumed automatically when running startup.bat
file: setenv.bat
#echo off
rem The proper way to set environment up for running Catalina
set "CATALINA_OPTS=-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n"
In my repo's subdirectory, I have some scripts with package main to show some example usage fo my package. But this gives me the following errors when being tested on Travis.
repo
example-dir
sub-dir
main.go // this gives me error like the following
github.com/~/directory-for-main-program
The command "go get -v ./..." failed. Retrying, 2 of 3.
I see this error only in Travis , not in local machine with go test.
Is there anyway to separate the main program and still able to pass the Travis testing?
Either use the correct path in your main.go, which is the proper way or use build constraints to disable that file:
// +build local
package main
//other code
then to locally build it use go build -tags local or go run -tags local