If I configure rolling restarts in enterprise passenger and then touch restart.txt, how do I check programmatically whether the process has been completed and can be guaranteed the old version is no longer being served?
I know it's been a while since the question was asked, but here is a piece of answer for others who, like me, found this question while googling:
When you do a "touch tmp/restart.txt", you can check passenger processes status using the command:
rvmsudo passenger-status
You'll then see some processes with a "rolling restart" line under them.
When it is finished you can also check the uptime of each passenger processes (using the same command).
Of course as you just restarted the passenger application, the uptime should be a couple seconds when the whole rolling restart is completed. This should be a proof that your application restarted correctly and uses the new version.
Finally if you want to be really really sure that your application uses the new version, you could just add a "version number" of your application in one of your views (maybe in your administration view or a secret view or in the legals of your website...).
You could use capistrano to automatically increment the version each time you deploy. (But if you use capistrano you don't need this 'version control' I think ;-) ).
Related
I've been using SonarQube for a year now and once I had been through all the installation process, I never got any problem... Until now.
I'm just trying to analyze a Maven Project (like I did several times before). To do so, I need to run the server first (port 9000). But when I launch "StartSonar.bat" (I'm on Windows), I get a huge log and finally the wrapper stops.
I think there is something wrong with the port 9000 although I'm not sure because I'm not that advanced with analysing logs and everything.
Here's a link to download the log I get
Thanks for your help!
The log states "Address already in use: bind" which means that some other tool already runs on that port. Choose another one should already do the trick.
Or there is a zombie-process still running (no clean shutdown). But you should see a process in the task manager - just kill that one. Usually a reboot should solve that too.
Run netstat -abo on the Windows command line to see which ports are used, by which programs they are used and their process IDs (PID). With the PID you can find the process in Task Manager and kill it there if necessary.
In a rails application I'm developing (on OS-X), I'm finding running the test suite via rspec locking up increasingly frequently. It does not happen every time. I've tried adding --format documentation when running the suite to see if it happens at the same place every time, and it does not.
I've tried killing the process with kill -9. It then changes the name to (ruby) with a process status of ?E. This link suggests that the process is blocked waiting for a system call to finish. I have to restart my machine every time this happens in order to kill this process.
I've tried re-installing rvm, ruby, mysql, and imagemagick. This project is using imagemagick (via the mini_magick) gem, and I suspected that it may be one of these commands that is causing rspec to block. I tried adding puts statements around each of the mini_magick commands to ensure they finish executing, and all looks fine.
I'm looking for suggestions on how to diagnose this issue.
It's possible your problem is an order-dependency bug, you can pass the seed along and the order will remain consistent.
RSpec prints out the random number it used to seed the randomizer.
Use this number to run rspec with the same order
--order rand:3455
This question already has answers here:
shell script to kill tomcat service if it is not stopped by stop command after certain amount of time?
(2 answers)
Closed 6 years ago.
I have tomcat downloaded on my computer (not installed as a service).
I am writing a script that upgrades a webapp running on the tomcat server. The script roughly works like this:
Stop tomcat
Perform several upgrade operations
Start tomcat
When performing the upgrade operations, I need to know that tomcat is fully stopped. However if I run $TOMCAT_HOME/bin/catalina.sh stop then that script exits before tomcat is actually stopped and if I execute the upgrade operations while tomcat is still running that might cause things to crash. In addition, the upgrade operations may finish quickly and this can cause the tomcat startup to execute before the shutdown is complete which causes tomcat to crash.
Right now my solution is to wait for 5 seconds after the shutdown is initiated but I am wondering if there is a more elegant solution to the problem.
One way to verify whether the process is still running is by using its process id. Depending on your installation, you should be able to find the process id of your tomcat server in:
/opt/tomcat/catalina.pid
In theory, if this file is empty, then the process should have ended although depending on the implementation and certain circumstances (tomcat crashing?) this might not be true. To be safe, you can take the pid found in this file and just check whether this process is still running.
ps -p <pid>
The above command will return the pid, the time and the command of the process if it is still active.
Another option would be to check if a certain port (the one that Tomcat uses) can be bound. If you can't bind on this port, it means that Tomcat is still running.
Anyway, Felix's solution is more appropriate and it's probably better to use it. I only wrote my suggestion in order to provide more alternatives, also not all Tomcat installations have catalina.pid (at least the default one doesn't).
INFO: I installed SymformSync the other day, a distributed cloud storage system, but deleted it again the same day. (I like the idea, but it's not suitable for someone on a laptop like me.) However, there's a process symformsync that keeps popping up and consuming pretty heavily on the CPU. I deleted the application, but this process still keeps popping up! Needless to say, I don't appreciate not having control over the processes on my own CPU!
Q: How do I find this process that keeps starting up by itself, and how do I delete it?
Answer from Symform:
Thank you for contacting Symform support. I understand that you are needing the instructions to remove Symform from your Mac.
Here is the information:
Access the Terminal program on your Mac, by going to the search tool in the upper right-hand corner, and entering in Terminal.
Once Terminal is open, enter in the following command, depending on what you want to do:
Normal uninstall will only stop the services and remove the software. It will leave the service configuration and log files in place.
sudo /Library/Application\ Support/Symform/scripts/uninstall
To completely remove all aspects of the Symform software, configuration, and logs, a purging operation is available as well. This will remove any synchronization and contribution supporting files and directories too.
sudo /Library/Application\ Support/Symform/scripts/uninstall --purge
You will need to enter in your Mac password when running either of these commands.
I'm currently installing qt4-mac and it's taking forever to build. I've searched around and I've discovered that it's going to take anywhere from 2-5 hours to install.
Is there a way to interrupt this installation process and if so do I need to do some clean-up afterwards?
Have you tried using control+c?
Also, I'm not entirely sure about cleanup, but according to the MacPorts docs, the command sudo port -fp uninstall --follow-dependents [your port name here] should help (this page is about uninstalling MacPorts itself, but it's the same command). I'm not sure how MacPorts treats interrupted installations and if it treats "half-installed" items as uninstallable, but it's worth a try.
This is an old thread, but I'd like to share my personal opinion on this.
Once upon a time (two years ago I guess, not sure about the current state of affairs) I interrupted a MacPorts update (sudo port upgrade outdated) with not Ctrl+C (roughly SIGINT), but rather SIGKILL, since I was running into some trouble with the hardware at that time. I ended up with a completely broken install that defied all efforts of clean-up or recovery, and I ended up restoring a full backup of /opt/local.
I never dare to interrupt MacPorts install/upgrade since then, even with Ctrl+C's.
The moral of the story is: interrupting MacPorts installation process could be potentially pretty dangerous. Leave it alone if it is simply running for a long time (sometimes building does take forever). If you do believe it is hanging rather than actually building, make sure you have a backup, and proceed with caution (of course, it's too late to back up when you are already running the install).
I also would like to chime in. I think a good practice is to watch where you are in the installation before Ctrl+Cing, then clean the dependency you were on and redo the main install later. For example, I was installing kdenlive and killed it in the middle of the virtuoso (one of many dependencies) install. Later, I did a sudo port -v selfupdate, then a port clean virtuoso, then started the kdenlive install again with sudo port install kdenlive. This seems to be a decent way to go; it cruised through the first part and picked up at normal speed when it got to virtuoso.
Don't press Ctrl+C
Building on the answer by 4ae1e1, while (s)he interrupted the process sending a SIGKILL signal, I interrupted it sending an actual SIGINT signal, i.e. the usual Ctrl+C, and now no MacPorts app are working so far.
So I completely agree with 4ae1e1.
If you need your machine
If you need to suspend the installation, e.g. because you need your CPU to be available for other things, to send a SIGSTOP signal instead, in order to pause the installation.
kill -STOP installationPIDs
Once you are ready to resume it, you can send a SIGCONT signal and you can complete it.
kill -CONT installationPIDs
You should easily find the PIDs of the installation process, for example you can just run htop and look among the processes using most of the CPU.
If you change your mind about an installation
Even if you change your mind and you do not want that port/package installed anymore, I strongly recommend to just complete the installation (pausing it when needed as suggested below) and just uninstall the port/package afterwards. It sounds like a waste of time, but it is the safest thing to do.