I want to bypass setting of JVMOptions in service.bat while creating tomcat service and use JAVA_OPTS set in catalina.bat starting service.
This is to avoid setting same jvm arguments twice as we can start using service or startup.bat
Is this possible
Thanks,
kusumat
There are 2 ways you can configure Tomcat Server on Windows OS either by service or standalone.
If you configure tomcat as a service , it will never call catalina.bat during start-up.
Same way, if you use standalone mode it uses only catalina.bat (won't use service.bat)
Decide the mode you are going to use and set the JVM options based on the mode.
Related
According to Creating and configuring instances and my own testing, the Google Container Optimized OS launches the specified container on instance startup.
However, I'd like to execute my own startup script which would include running the container. Is there any way to prevent this default behaviour of automatically running the container on startup?
Specifiying a custom startup script for the instance doesn't seem to prevent the default behaviour.
You can create a COS instance and either specify a cloud-init or a startup script.
Then use gcloud compute instances create (rather than gcloud compute instances create-with-container) and --metadata-from-file or --metadata=startup-script= respectively.
I've written a check_mk Nagios plugin that is monitoring a REST API. I only want a single instance of this service/script on the entire monitoring service, not a service instance per host.
However, when I add the script to the /local/lib/nagios/plugin directory and configure a classical activate & passive monitoring check in WATO, it creates a service for each host.
Is this possible or am I doing this the wrong way?
Dropping scripts in /opt/omd/sites/{site}/local/lib/nagios/plugins, then defining custom checks in /opt/omd/sites/{site}/etc/check_mk/conf.d/wato/rules.mk is how I ended up having a single check.
I’m having problems admin’ing my cluster. I can run ‘standalone -c clustered.xml’ on Windows and everything looks ok. However, if I run ‘domain.bat’ I can’t see how to configure the domain.xml file so that it can see anything else on my local server. Is this somehow related to the host.xml file?
The domain mode is for administration, you can configure servers in cluster mode.
If you start with domain.[bat||sh] there are at least two java processes running.
A HostController, for administration/configuration and a ProcessController to start/stop or restart configured processes.
The domain.xml contains the configuration and here the profile is stored, i.e. caches, endpoints, ports, security etc.
The host.xml contains the server for this host-machine and the link to the domain-master.
Configuration is possible via console GUI or CLI commandline.
I have a DockerFile that starts 2 processes in a single docker container using a jar file and a config file as an argument
java -jar process1.jar process1.cfg &
java -jar process2.jar process2.cfg
process1.cfg and process2.cfg are residing in mounted directories. Now whenever there is a change in any of the cfg files, I would need to restart the corresponding process for the new change to take effect. All these to be done programmatically using Java in a REST microservice that updates the config file and restarts the process. Any idea on how to go about it ?
The problem can be generically solved by your Java app starting a config change monitoring service/thread, which manages the actual business service/thread(s) by starting it in the beginning and restarting on any change (if the change actually needs a restart). File change monitoring is standard Java functionality. The solution does not need any REST, it is not bound to microservice architecture (although it is more sensible within it) and it is not limited by or to docker containers.
If you do not want any file-based configs, do the same, but the monitoring bit can be e.g. a vert.x-based web server listening for external REST requests supplying configs, on start or for any update. The rest remains the same.
In my current workplace we actually have a module that functions in exactly this way, it is deployed to a docker and uses both file system monitoring and vert.x web server for config changes.
You can even go further and make the monitoring bit start multiple instances internally if multiple configs need to be supported.
These two parts are together because I think they're related to each other.
I'm running Jenkins' latest LTS war file (v1.596.2) directly from the command line. I'm using an Openshift DIY cartridge to do this.
I have set my "JENKINS_HOME" environment variable to "$OPENSHIFT_DATA_DIR/jenkins".
export JENKINS_HOME=$OPENSHIFT_DATA_DIR/jenkins
Part 1: where is my config.xml file?
This works fine and most files seem to have been stored there fine, but I can't find the config.xml file... I'm probably overlooking something but I can't find it anywhere!
Part 2: Boot up error
I also have this error when I boot up my server using:
java -jar jenkins.war --httpListenAddress=$OPENSHIFT_DIY_IP --ajp13Port=-1
It shows this error message in the console:
http://pastebin.com/30eBBHN5
The server does boot, but it just shows this screen:
http://i.imgur.com/PKVydeP.png
I know Openshift only allows you to bind to port 8080, otherwise you have to bind to a private port in the range 15000 - 35530 (see this). However, I couldn't find any documentation on what ports Jenkins tries to bind or how to change the bindings, other than the main http (8080) and https (not used) ports.
(my jenkins cartridge URL - may not be running)
Any ideas as to what I should try?
The config.xml (https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins) according to that page is stored in the JENKINS_HOME location, you need to create it there (along with any other configuration files that you need). You should be set with having set your JENKINS_HOME to a folder in your OPENSHIFT_DATA_DIR.
As for the port issue. You might check out the current Jenkins cartridge that OpenShift provides (https://github.com/openshift/origin-server/tree/master/cartridges/openshift-origin-cartridge-jenkins) and check out some of the configuration files they are using, or their startup commands and see if that information helps you get yours running.
Also, don't use export JENKINS_HOME=$OPENSHIFT_DATA_DIR/jenkins
use this "rhc set-env " instead, it's much safer than exporting...