goanywhere.sh stop - not killing java process, automating restart
Post any question you may have in regards to GoAnywhere Director and let our talented support staff and other users assist you.
4 posts
Page 1 of 1
We've recently had to restart goanywhere several times. When executing the stop script (./goanywhere.sh stop) we've noticed that it is not stopping the director evoked java process so we have to find the corresponding pid and manually kill the process before starting goanywhere. Has anyone else experienced something similar?
Also is anyone auto restarting their goanywhere instance? We're considering adding a recurring stop/start task in cron and was just curious if anyone has done something like this.
Thanks
Also is anyone auto restarting their goanywhere instance? We're considering adding a recurring stop/start task in cron and was just curious if anyone has done something like this.
Thanks
- Support Specialist
- Posts: 590
- Joined: Tue Jul 17, 2012 2:12 pm
- Location: Phoenix, AZ
-
Normally, the shutdown process works without issue. I'm not sure what would be holding the job and keeping it from shutting down, but that is something that we could look through the system and tomcat joblogs to review and see if anything stands out.
As for doing the automated restart, I would be very careful doing this. You would need to make sure that there is nothing running/transferring at the designated time or that could be ended without notice.
As for doing the automated restart, I would be very careful doing this. You would need to make sure that there is nothing running/transferring at the designated time or that could be ended without notice.
Rick Elliott
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696
Rick- Thanks for responding. I can submit a request to further investigate the orphan pid issue.
When we execute the ./goanywhere.sh STOP command, i was under the impression that in normal conditions the scheduler, monitor and triggers engines stopped--allowing current processes to finish. If that is the case, I'm not sure I follow your state about ensuring nothing is running/transferring. Can you provide an example when something could begin transferring when the engines are stopping?
When we execute the ./goanywhere.sh STOP command, i was under the impression that in normal conditions the scheduler, monitor and triggers engines stopped--allowing current processes to finish. If that is the case, I'm not sure I follow your state about ensuring nothing is running/transferring. Can you provide an example when something could begin transferring when the engines are stopping?
- Support Specialist
- Posts: 590
- Joined: Tue Jul 17, 2012 2:12 pm
- Location: Phoenix, AZ
-
The intent here is to practice caution. A big issue is impatience when ending/restarting GAMFT. If something is running and you think it should have stopped then you kill by the PID, it could cause issues. Same for scheduling or implicitly by PID.
Just stating to be careful and plan around what you're trying to accomplish.
Just stating to be careful and plan around what you're trying to accomplish.
Rick Elliott
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696
4 posts
Page 1 of 1