I was trying to debug the webapp so i wanted to attach remote debugger to apache tomcat. But when i run the command "catalina.sh jdpa start" it doesn't start the server instead it shows me this
./catalina.sh jdpa run
Using CATALINA_BASE: /Users/rsingh/work/apache-tomcat-7.0.27*
Using CATALINA_HOME: /Users/rsingh/work/apache-tomcat-7.0.27
Using CATALINA_TMPDIR: /Users/rsingh/work/apache-tomcat-7.0.27/temp
Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home
Using CLASSPATH: /Users/rsingh/work/apache-tomcat- 7.0.27/bin/bootstrap.jar:/Users/rsingh/work/apache-tomcat-7.0.27/bin/tomcat-juli.jar
Usage: catalina.sh ( commands ... )
commands:
debug Start Catalina in a debugger
debug -security Debug Catalina with a security manager
jpda start Start Catalina under JPDA debugger
run Start Catalina in the current window
run -security Start in the current window with security manager
start Start Catalina in a separate window
start -security Start in a separate window with security manager
stop Stop Catalina, waiting up to 5 seconds for the process to end
stop n Stop Catalina, waiting up to n seconds for the process to end
stop -force Stop Catalina, wait up to 5 seconds and then use kill -KILL if still running
stop n -force Stop Catalina, wait up to n seconds and then use kill -KILL if still running
configtest Run a basic syntax check on server.xml - check exit code for result
version What version of tomcat are you running?
Note: Waiting for the process to end and use of the -force option require that $CATALINA_PID is defined*
I do not see the logs file being created for apache and i do not see any error in the syntax i am starting the server with. Has anyone ever faced it?
You have a typo ("p" and "d" reversed). The command should be:
catalina.sh jpda start
Related
Performing a simple test to debug a LUA script, redis-cli gets stuck and does not accept any input. They only way of ending the session is doing Ctrl+C
c:>cd "\Program Files\Redis"
c:\Program Files\Redis>echo return ARGV[1] + ARGV[2] > test.lua
c:\Program Files\Redis>redis-cli --ldb --eval test.lua , 2 3
Lua debugging session started, please use:
quit -- End the session.
restart -- Restart the script in debug mode again.
help -- Show Lua script debugging commands.
From that point the application does not accept any input.
I am using latest release (3.2.100) from https://github.com/MSOpenTech.
Do I need to do anything special to make the debugging work in Redis for Windows?
I am not sure if the problem with debugging is because redis-server.exe or redis-cli.exe, since I do not have a Linux machine at hand.
UPDATE
I can now confirm I can debug a script using redis-cli.exe in windows, connecting to a Redis instance in Linux. So the problem seems to be redis-server.exe.
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"
Title says it all... just trying to get glassfish up and going. This is the error I get
Detected server admin port: 4848
[2015-04-06 07:37:56,138] Artifact java_web_app:war exploded: Server is not connected. Deploy is not available.
Detected server http port: 8080
Command start-domain failed.
JVM failed to start: com.sun.enterprise.admin.launcher.GFLauncherException: The server exited prematurely with exit code 1.
Before it died, it produced the following output:
This subcommand requires root privileges: bsexec
Surely there's a way around this? I don't really want to run Intellij with sudo every time.
Answer: GlassFish 4.1, IntelliJ IDEA 14.1
I have no idea (pun not intended) why GlassFish requires a root user account.
You need to execute something like this:
/Library/opt/payara-4.1.151/glassfish/bin/asadmin start-domain --verbose=true domain1
Go Run -> Edit Configuration -> Select configuration (acme-payara-project) -> Start Up Configuration
Edit the Startup Script and change it to add the --verbose-true parameter.
Is this a problem happening on Mac OSX 10.10.3?
If so, we were able to workaround the problem by changing the content of the file /usr/libexec/StartupItemContext to
#!/bin/sh
unset LAUNCHD_SOCKET
$#
We've also reported this workaround on the corresponding glassfish-issue: https://java.net/jira/browse/GLASSFISH-21343
Note that this will only work for glassfish 4.0. In 4.1 they changed the startup code, so this StartupItemContext file will no longer be used.
If your glassfish Version is 4.1, the only known workaround at the moment is to start glassfish with the --verbose=true param.
Solved this on OS X 10.10.4, IntelliJ 14.1.4 by adding -v to the startup script.
Changing the Startup command in the Run Configuration under the "StartUp/Connection" tab to the following worked for me:
.../glassfish-4.1/glassfish/bin/asadmin start-domain --verbose domain1
Jenkins version: 1.574
I created a simple job which performs the following:
Using "Execute shell script on remote host using SSH" as one of the BUILD steps, I'm just calling a shell script. This shell script performs stop and start operations on Tomcat to restart an application on the target machine.
I have a valid username, password, port defined for the target SSH server in Jenkins Global settings.
I saw this behavior that when I run a Jenkins job and call the restart script (which gets the application name as parameter $1), it works fine, but as soon as "Execute shell script on remote host using SSH" step completes, I see the new process dies on the remote/target application server.
If I run the script from the target/remote server itself, everything works fine and the new process/PID remains live forever, but running the same script from Jenkins, though I don't see any errors and everything works as expected, the new process dies as soon as the above mentioned SSH step is complete and control comes back to the next BUILD step in Jenkins job OR the Jenkins job is complete.
I saw a few posts/blogs and tried setting: BUILD_ID=dontKillMe in the Jenkins job (in various places i.e. Prepare Environment variables and also using Inject Environment variables...). When the job's particular build# is complete, I can see Environment Variables for that build# does say BUILD_ID=dontKillMe as its value (instead of the default Timestamp tag value).
I tried putting nohup before calling the restart script, i.e.,
nohup restart_tomcat.sh "${app}"
I also tried:
BUILD_ID=dontKillMe nohup restart_tomcat.sh "${app}"
This doesn't give any error and creates a nohup.out file on the remote server (but I'm not worried about it as the restart_tomcat.sh script itself creates its own LOG file which I'm "cat"ing after the restart_tomcat.sh script is complete. cat'ing on the log file is performed using another "Execute shell script on remote host using SSH" build step, and it successfully shows the log file created by the restart script).
I don't know what I'm missing at this point, but as soon as the restart_tomcat.sh step is complete, the new PID/process on the remote/target server dies.
How can I fix this?
I've been through this myself.
On my first iteration, before I knew about Jenkins ProcessTreeKiller, I ended up just daemonizing Tomcat. The Apache Tomcat documentation includes a section on running as a daemon.
You can also try disabling the ProcessTreeKiller for your whole Jenkins instance, if it's relatively small (read the first link for information).
The BUILD_ID=dontKillMe should be passed to the shell, and therefore it should be in your command line, not in Jenkins global configuration or job parameters.
BUILD_ID=dontKillMe restart_tomcat.sh "${app}" should have worked without problems.
You can also try nohup restart_tomcat.sh "${app}" & with the & at the end.
My solution (it worked after trying everything else) in Ubuntu 14.04 (Trusty Tahr) (Amazon AWS - Amazon EC2), Jenkins 1.601:
Exec command: (setsid COMMAND < /dev/null > /dev/null 2>&1 &);
Exec in PTY: DISABLED
// Example COMMAND=socat TCP4-LISTEN:1337,fork TCP4:127.0.0.1:1338
I created this Transfer as my last one.
#!/bin/ksh
export BUILD_ID=dontKillMe
I added the above line to the start of my script and the issue was resolved.
I am trying to get ActiveMQ server running on a RaspberryPI Debian Squeeze box and all appears to be installed correctly but when I try and start the service I am getting the following...
root#raspberrypi:/var/www/activemq/apache-activemq-5.7.0# bin/activemq
INFO: Loading '/etc/default/activemq'
INFO: Using java '/usr/jre1.7.0_07/bin/java'
/usr/jre1.7.0_07/bin/java: 1: /usr/jre1.7.0_07/bin/java:ELF0
4°: not found
/usr/jre1.7.0_07/bin/java: 2: /usr/jre1.7.0_07/bin/java: Syntax error: "(" unexpected
Tasks provided by the sysv init script:
restart - stop running instance (if there is one), start new instance
console - start broker in foreground, useful for debugging purposes
status - check if activemq process is running
setup - create the specified configuration file for this init script
(see next usage section)
Configuration of this script:
The configuration of this script can be placed on /etc/default/activemq or /root/.activemqrc.
To use additional configurations for running multiple instances on the same operating system
rename or symlink script to a name matching to activemq-instance-<INSTANCENAME>.
This changes the configuration location to /etc/default/activemq-instance-<INSTANCENAME> and
$HOME/.activemqrc-instance-<INSTANCENAME>. Configuration files in /etc have higher precedence.
root#raspberrypi:/var/www/activemq/apache-activemq-5.7.0#
It looks like there is an error somewhere but I am a fairly newbie at this and don't know where to look.
Just adding an answer since,becoz as per the documentation , the command is wrong
to start activemqm, use
Navigate to [installation directory/bin] and run ./activemq start or simple bin/activemq start
if you want to see it live in a window use bin/activemq console
To stop, you have to kill the process
The default ActiveMQ "getting started" link sends u here : http://activemq.apache.org/getting-started.html which is the "Getting Started Guide for ActiveMQ 4.x".
If you scroll down main documentation page, you will find this link with the proper commands :
http://activemq.apache.org/version-5-getting-started.html