Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#71034 - [matterbridge] use network-online.target instead of network.target and add restart on failure
Attached to Project:
Community Packages
Opened by Daniel Micay (thestinger) - Thursday, 27 May 2021, 01:45 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Monday, 19 July 2021, 21:38 GMT
Opened by Daniel Micay (thestinger) - Thursday, 27 May 2021, 01:45 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Monday, 19 July 2021, 21:38 GMT
|
Detailsmatterbridge doesn't handle not having network access at launch gracefully. It will exit with a non-zero exit status rather than retrying. Using network.target doesn't work properly. It should be network-online.target to avoid failing to connect after reboot in the common case. It only works right now if you happen to get a working connection before it has started connecting.
It also needs Restart=on-failure and RestartSec=5s in case the network connections fail despite network-online.target. It does properly handle reconnecting after the initial start-up if the connections die in most cases. Right now, the included service doesn't provide a reliable matterbridge service. It usually fails to work after rebooting the server with my setup. Overriding the unit with these changes fixes it. I'm not sure why they treat it differently at first launch. It's strange for a service that's run persistently rather than something used interactively. |
This task depends upon
Closed by Bruno Pagani (ArchangeGabriel)
Monday, 19 July 2021, 21:38 GMT
Reason for closing: Implemented
Additional comments about closing: Done in 1.22.3-2, thanks for the report.
Monday, 19 July 2021, 21:38 GMT
Reason for closing: Implemented
Additional comments about closing: Done in 1.22.3-2, thanks for the report.