Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addon stops when connection/forwarding fails #17

Open
ThomDietrich opened this issue Oct 27, 2023 · 3 comments
Open

Addon stops when connection/forwarding fails #17

ThomDietrich opened this issue Oct 27, 2023 · 3 comments

Comments

@ThomDietrich
Copy link
Owner

ThomDietrich commented Oct 27, 2023

We had a power outage today. This lead to a weird constellation in which the autossh-addon wasn't able to connect and stopped after the run script was finished.

I assume there are similar causes for connection issues and I would like to ensure that the addon never stops trying to reconnect.

I see three options to fix this:

  1. Fix my specific issue by setting the following line to "no" - not sure what that will do exactly
    "-o ExitOnForwardFailure=yes "\
  2. Put the autossh command into an endless loop - that would certainly help
  3. Make use of supervisor watchdog "will restart the addon when it fails" - I don't know how it works and what fails means. Is it a simple exit 1?

Option 3 is my favorite overall.

What do you think?

@Rjevski
Copy link

Rjevski commented May 12, 2024

I've encountered this issue a few times now so I'm keen to get this resolved.

Option 1 will not do anything. That setting only controls the behavior of the SSH client process when the SSH connection itself succeeded but forwarding the port failed (let's say the remote port is already occupied on the remote host).

In our case the issue is very likely to be networking (the add-on starts trying to connect before the network connection is up) so we wouldn't even get to a stage where that setting becomes relevant anyway, but even if it did, having ssh stay running after failing to forward the port would be useless to us anyway.

Option 2 is the solution.

Option 3 is not a full solution. I have it enabled and yes it looks like it behaves like you described. The problem is that it has a max number of restarts and/or has a "burst" limit where lots of restarts in a short time will cause the watchdog to give up.

@ThomDietrich
Copy link
Owner Author

@Rjevski thanks for your response. I favored option 3 under the assumption that this watchdog behavior can be influenced. It did follow an infinite restart pattern some time ago and the "giving up" strategy is changed behavior since then. I wonder if that can be configured per add-on, which would make this the best solution. Long story short: I never looked into the behavior of the watchdog. Do you have any further knowledge?

After we have rules out option 3 as a viable option, I am more than happy to implement option 2 or to accept a PR.

@Rjevski
Copy link

Rjevski commented May 15, 2024

I have opened the PR above - would you be able to test the following:

  • starting add-on with broken/unavailable SSH server - you should see the add-on continue to run and retry forever - if you fix your SSH server it should automatically connect
  • stopping the add-on from the Home Assistant add-ons UI - the add-on should still stop properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants