Sometimes when I want to stop or start edx services using /edx/bin/supervisorctl It doesn’t end for a long time without any reaction. then when I terminate it with Ctrl+C I get this traceback:
I tailed log files looking for something useful to debug but nothing I found. Amazingly in the background it does what it supposed to do. For example if I run the script to start lms then wait for a minuet and terminate it, lms starts. I can guess that it’s a network problem but I cannot debug and fix it.
I confused and decided to request for the community helps and advice.
Thanks in advance
Whenever you’ll interrupt on going commands you’ll get that.
And I don’t think that there should be any issues in supervisorctl taking a bit of time in restarting all the processes, that depends on power of your machine, but don’t worry, unless it’s taking more than 5 minutes you should not worry about it.
Another solution would be to list all the process and only restart the ones that you need to, for example if you’ve made a change in lms code, only restart lms.
However, if your restart is taking infinite time or is not showing anything, I don’t know what to do there.
Thank you @chintan for your answer,
I don’t think that it happened because of system power. It was well working before Thursday and such amazingly it works well now!!! I restarted lms in just 2 seconds today. but in my last try on Thursday it took more than 5 minutes and finally I terminate it. I explained that if I terminate each of start/stop commands after 10 seconds, the action was successfully done. Like that the extra time was for ensuring about the result of the action which was unsuccessfully repeating in a loop.
Again thank you very much for your time
I’ll inform everybody here if I find more
Surprisingly today this problem appeared again. This time I tried to start a single service as @chintan said. After more than half an hour it has not returned to the shell yet. In addition I opened a new terminal and checked the status of the LMS service and I found that lms is running with 44 minutes uptime.
Another thing to mention is that rabbitMQ status shows some errors like:
epmd: node name already occupied rabbitmq-cli-11
I don’t know they are relevant or not. But I don’t think so.