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

metserver (& metclient) error message control #27

Open
wehimwich opened this issue Apr 14, 2020 · 1 comment
Open

metserver (& metclient) error message control #27

wehimwich opened this issue Apr 14, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@wehimwich
Copy link
Member

It would be nice to have a facility to suppress metserver (and maybe metclient) error e-mails when their is a known problem, e.g., the device is disconnected, without having to disable it. That way it could recover automatically when it comes back on line.

There might be something fancier that would be better, but a simple approach might be have a file in /usr2/control that the daemon reads. If it doesn't exist, processing is normal. If it does exist, it has a time limit/epoch for how long to suppress the e-mails, including options for indefinitely and until it recovers. Maybe deleting the file would be a simple way for the operator to restore it immediately.

@wehimwich wehimwich added the enhancement New feature or request label Apr 14, 2020
@wehimwich
Copy link
Member Author

Consider expanding this conceptually to be a cut-off switch. That way metserver (& metclient) could be running on two machines and could be simply disabled/enabled by the operator depending on which is operational (and has the connector, if serial).

It seems like it would be nice if this could be automagically detected, but having the two machines communicate to decide who has the device seems too complicated and it is probably better if there is active control. Otherwise one could go a long way down a road optimizing this for many different unlikely fall-over scenarios.

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

No branches or pull requests

1 participant