Closed AmarOk1412 closed 5 years ago
Should be enough. The only problematic case will be if "restart jitsi-video-bridge" is not notified. But I think this case is unlikely. Another approach can be to move the handler in tasks/
and always stop and restarts services in a "good way".
Thanks @AmarOk1412. You would like to contribute also in this PR the changes when notifying the handlers?
This PR is ok for me. I don't think I need to add something more :)
Sorry, you were right. I had not paid attention to the listen
argument. I'm going to merge your PR.
Although this solves the problem that we are discussing here, I would like later to be able to solve it in the "correct" way, making real restarts. I will open an issue for this and already thanks the contributions
By real restarts, you mean removing the handlers and add at the end a "restart services" task?
By real restarts, you mean removing the handlers and add at the end a "restart services" task?
With "real restarts" I meant to keep the handlers as before, doing only restart of services, but without mysteriously skipping.
Oh indeed, your handlers are skipped from your side. Is it the case on your host or a fresh host? Because if nothing changes, the notify is not launched.
It happened to me in both scenarios. The execution of the role in a fresh host ended like this:
RUNNING HANDLER [jitsi_meet : restart nginx] ************************
skipping: [my-server.org]
RUNNING HANDLER [jitsi_meet : restart prosody] ************************
skipping: [my-server.org]
RUNNING HANDLER [jitsi_meet : restart jicofo] ************************
skipping: [my-server.org]
RUNNING HANDLER [jitsi_meet : restart jitsi-videobridge] ************************
skipping: [my-server.org]```
right. So like my previous answer I don't have any idea for this problem.
Because jitsi-video-bridge can take the port 443, nginx should ensure that all jitsi services are correctly stopped.