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

Docs bug - os_service is not implemented on linux. #19037

Open
the-maldridge opened this issue Oct 2, 2023 · 6 comments
Open

Docs bug - os_service is not implemented on linux. #19037

the-maldridge opened this issue Oct 2, 2023 · 6 comments
Labels
type/docs Documentation needs to be created/updated/clarified

Comments

@the-maldridge
Copy link

the-maldridge commented Oct 2, 2023

Overview of the Issue

The documentation clearly states that os_service supports both windows and systemd service types. However systemd support is unimplemented. Either the docs should be updated to reflect reality, or the support should be implemented.


Reproduction Steps

Consul info for both Client and Server

N/A

Operating system and Environment details

Debian 11, amd64.

Log Fragments

Oct 02 18:12:15 consul-demo1 consul[14100]: 2023-10-02T18:12:15.469Z [ERROR] agent: error creating OS Service client: error="not implemented"
@im2nguyen im2nguyen added the type/docs Documentation needs to be created/updated/clarified label Oct 18, 2023
@im2nguyen
Copy link
Contributor

@david-yu can you help confirm this? i can update the docs to reflect the current functionality

@jkirschner-hashicorp
Copy link
Contributor

Only windows is supported, not systemd/unix. The documentation is inaccurate*.

Reference: The os_service_unix.go source file makes it clear that unix isn't supported yet. The original PR intentionally only addressed this for Windows.

*The original PR author probably felt the docs were accurate, because you technically can specify a SystemD type... but if you do that, you'll get "not implemented" errors.

@the-maldridge
Copy link
Author

While technically accurate, this is not the expectation I hold as an end user. Per the principle of least surprise, if something is flagged as a supported option I would expect that configuring it does not result in an error.

@jkirschner-hashicorp
Copy link
Contributor

Totally agree @the-maldridge. Technically correct is the worst kind of correct ;)

Out of curiosity, what are you doing instead (since the OS Service health check type doesn't exist for Linux)? And how adequate of an alternative is that?

If I remember correctly, we implemented OS Service health checks on Windows primarily because trying to do the equivalent with a script check had a really high overhead on Windows, whereas it didn't on Linux. More details here.

@the-maldridge
Copy link
Author

I use just an http service check, but I've occasionally had that return interesting results, so I was wanting to enable OS checks as well so that I could alert on the condition where systemd thinks something is up but the service itself disagrees.

@vftaylor
Copy link

vftaylor commented May 14, 2024

Hello lovely people. Awaiting this to be implemented on Linux, but in the meantime @the-maldridge @jkirschner-hashicorp for anyone that comes across this you can simply use a script check e.g.:

{
  "service": {
    "name": "dhcp",
    "check": {
      "args": ["/usr/bin/systemctl", "is-active", "kea-dhcp4-server"],
      "interval": "10s"
    }
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/docs Documentation needs to be created/updated/clarified
Projects
None yet
Development

No branches or pull requests

4 participants