I am using a software which comes as a source tarball and maven pom.xml which builds a war and eventually gets run like this:
mvn tomcat:run -Dmaven.tomcat.port=1234
When I run this command in the background, I am unable to subsequently shutdown this server using
mvn tomcat:shutdown -Dmaven.tomcat.port=1234
I have not found a way to define a shutdown port when starting, nor any documentation if the tomcat which is started that way uses any other of the ports that are normally used in the standard Tomcat configuration, especially the shutdown port and shutdown string. It looks as if not, but can anyone confirm this? Does this mean then that the only way to shutdown the server is by explicitly killing the process? But what is the purpose of the tomcat:shutdown then?
Related
Q1
I installed jenkins on linux using the jenkins repo. It's up and running fine. I thought it was running on nginx or apache so I could change the hostname and install certificates but I read somewhere that it's most likely using a small java servlet called jetty???? I'm a devops student and want to go about this the right way for future production workloads. Is there a way to access the jetty server to make production ready network and security updates? Should I instead redo the server and install jenkins on tomcat so I can make these changes? Orrrrr, should I install nginx alongside whatever is running jenkins? TIA.
Q2
I tried systemctl status nginx, httpd, tomcat, tc, http, apache2, jetty. How do you find what server is running jenkins. I assume there may be a java command that could tell me where the jenkins.war is being served from?
1.Jenkins is a java application, so it will use a java servlet container. By default, it uses Jetty, but you can also use Tomcat. If you want to use nginx,
you'll need to configure it to reverse proxy to the servlet container.
2.You can find the process running Jenkins by running ps -ef | grep jenkins. This will give you a list of all processes running on your system that contain the word "jenkins". The first column is the process ID, and the second column is the command that started the process.
I have already deployed some jar in JBoss Fuse server which is exposing two rest endpoint on port 9001 and 9002. Now i have made some changes in source code and want to deploy a new jar. Since i am doing hot deployment i am just calling ./karaf stop and placing new jar in fuseinstallDir/deploy . But when i start Karaf server using fuseinstallDir/start then i am getting java.net.BindException: Address already in use. I have tried to check which process is using this port but didnt get any process after stopping karaf server
You should hot-deploy while the server is running, not while its stopped. Because it will startup the old application first as it was not uninstalled first.
Also its not recommended to deploy via copying files to the deploy folder. Install install via the commands from the shell.
my group and I are running a server that is based upon Django and uses mod_wsgi to run an Apache server. We will not be working on this project after it is over, so I am attempting to set up cronjob similar functionality to check if the apache server has shut down(system restart or power failure), and if it has, will restart the server for me. I've found documentation on how to check if an apache server is down and restart the server if it is, but our server uses https and thus our start command is pretty verbose.
Can I simply use the functionality provided in these examples:
https://askubuntu.com/questions/277389/cron-job-to-restart-apache
https://www.digitalocean.com/community/tutorials/how-to-use-a-simple-bash-script-to-restart-server-programs
Or do I need a much more complicated process to make this happen?
The command we use to initially start the server is
python manage.py runmodwsgi --host 0.0.0.0 --port 8001 --https-port 8000 --ssl-certificate (certificate Location) --server-name (Domain Name)
I'm pretty new to Linux and using both Mod-wsgi as well as Apache so any help is greatly appreciated.
I suppose it is not good way to resolve this problem.
I recommend you use monit (https://mmonit.com/). It is cool program for checking services.
apt-get install monit
Apache restart configuration directives:
check process httpd with pidfile /var/run/httpd.pid
group apache
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed host 127.0.0.1 port 80
protocol http then restart
if 5 restarts within 5 cycles then timeout
You are better off using the --setup-only option to mod_wsgi-express or the Django integration for it, to generate the configuration but not run it. Then as others have mentioned, integrate it into the system service manager.
The two commands for starting and stopping the Apache/mod_wsgi instance would be apachectl start and apachectl stop, where apachectl is that which was generated when running with the additional --setup-only option.
When running it as a system service, also make sure you use the --server-root option to specify a more persistent location for the generated configuration. Do not use the default under /tmp if running for anything but temporary development sessions as some Linux systems will remove files under /tmp causing things to start failing after a while.
Also, since under a service manager it would generally be starting as root, particularly if listening on port 80 is a requirement, ensure you use the --user and --group options to specify what user/group your Python web application should run as.
Read:
https://pypi.python.org/pypi/mod_wsgi
for more details of the --setup-only option and start-server commands for generating the configuration. Because you are using the Django integration, you will need to use the --setup-only option.
For more informed helped, bring your issue to the mod_wsgi mailing list. The mod_wsgi-express way of running Apache/mod_wsgi is new enough that unlikely that anyone here is really going to know much about it.
There is no need to do this at all. There is no reason to start up Apache manually; once it's installed as a system service, Ubuntu will start it up automatically on restart or crash.
You should reflect on why you feel the need to do this for Apache specifically, and not any of the other system services you depend on, such as the database.
I am trying to start two instances of Jetty in different ports (one is 8080 and the other is 443).
I created two jetty.base directories using start.jar with the parameter --add-to-startd.
When I run "java -jar /opt/jetty/start.jar" in the first app directory it starts normally, port 8080.
When I run "java -jar /opt/jetty/start.jar" in the second app directory, it kills the first process. And after that starts normally, port 443.
If I change the order the same thing happens.
How can I run more than one instance of Jetty without one killing the other?
Jetty: jetty-distribution-9.3.0.M2
Java: jdk1.8.0_25
Operating system: Linux CentOS release 6.6
I found the problem, the process died because the server was out of memory.
I didn't see any Exception in the logs, but monitoring the machine, I saw that when the memory was close to 100% the process died.
I'm gonna deploy a Node.js mobile web application on two remote servers.(Linux OS)
I'm using SVN server to manage my project source code.
To simply and clearly manage the app, I decided to use Jenkins.
I'm new to Jenkins so it was a quite difficult task installing and configuring Jenkins.
But I couldn't find how to set up Jenkins to build remote servers simultaneously.
Could you help me?
You should look into supervisor. It's language and application type agnostic, it just takes care of (re-) starting application.
So in your jenkins build:
You update your code from SVN
You run your unit tests (definitely a good idea)
You either launch an svn update on each host or copy the current content to them (I'd recommend this because there are many ways to make SVN fail and this allows to include SVN_REVISION in the some .JS file for instance)
You execute on each host: fuser -k -n tcp $DAEMON_PORT, this will kill the currently running application with the port $DAEMON_PORT (the one you use in your node.js's app)
And the best is obviously that it will automatically start your node.js at system's startup (provided supervisor is correctly installed (apt-get install supervisor on Debian)) and restart it in case of failure.
A node.js supervisord's subconfig looks like this:
# /etc/supervisor/conf.d/my-node-app.conf
[program:my-node-app]
user = running-user
environment = NODE_ENV=production
directory = /usr/local/share/dir_app
command = node app.js
stderr_logfile = /var/log/supervisor/my-node-app-stderr.log
stdout_logfile = /var/log/supervisor/my-node-app-stdout.log
There are many configuration parameters.
Note: There is a node.js's supervisor, it's not the one I'm talking about and I haven't tested it.
per Linux OS, you need to ssh to your hosts to run command to get application updated:
work out the workflow of application update in shell script. Especially you need to daemonize your node app so that a completed jenkins job execution will not kill your app when exits. Here's a nice article to tell how to do this: Running node.js Apps With Upstart, or you can refer to pure nodejs tech like forever. Assume you worked out a script under /etc/init.d/myNodeApp
ssh to your Linux OS from jenkins. so you need to make sure the ssh private key file has been copied to /var/lib/jenkins/.ssh/id_rsa with the ownership of jenkins user
Here's an example shell step in jenkins job configuration:
ssh <your application ip> "service myNodeApp stop; cd /ur/app/dir; svn update; service myNodeApp restart"