Skip to content

bsdinit.service(running=True) is not idempotent for non-base-install services #1844

Description

@aqw

Describe the bug

bsdinit.service(running=True) is not idempotent for non-base-install services on OpenBSD.

The following code will always execute, regardless if the service is already running:

    bsdinit.service(
        service="node_exporter",
        running=True,
        _sudo=True,
    )

However, this seems to only be a problem with services that are are not part of the base install. The above code is idempotent with the service "unbound", which is part of the base install. I have not exhaustively tested this theory, but it holds true for 3 base-install services (unbound, tftpd, ntpd) and 3 services installed via pkg_add (node_exporter, unbound_exporter, isc_dhcpd).

Looking at bsdinit's source, I suspected that the issue is with the RcdStatus fact; however, when I run the shell code on the OpenBSD machine, everything returns as I would expect:

for SERVICE in `find /etc/rc.d /usr/local/etc/rc.d -type f`; do $SERVICE status 2> /dev/null || $SERVICE check 2> /dev/null ; echo "`basename $SERVICE`=$?" ; done
...
unbound(ok)
unbound=0
...
node_exporter(ok)
node_exporter=0
...

Looking at the permissions of the rc files themselves:

rtr5$ ls -lah /etc/rc.d/{tftpd,unbound,ntpd,node_exporter,unbound_exporter,isc_dhcpd} 
-rwxr-xr-x  1 root  bin     137B Oct  9  2025 /etc/rc.d/isc_dhcpd
-rwxr-xr-x  1 root  bin     181B Oct  9  2025 /etc/rc.d/node_exporter
-r-xr-xr-x  1 root  wheel   137B Oct 12  2025 /etc/rc.d/ntpd
-r-xr-xr-x  1 root  wheel   164B Oct 12  2025 /etc/rc.d/tftpd
-r-xr-xr-x  1 root  wheel   372B Oct 12  2025 /etc/rc.d/unbound
-rwxr-xr-x  1 root  bin     251B Oct  9  2025 /etc/rc.d/unbound_exporter

The permissions do not look problematic, but just in case, I altered node_exporter to match to base-install services. It did not change the behavior.

So I'm left with opening a bug report for now, without an accompanying PR.

Any ideas for further investigation is most welcome. :-)

To Reproduce

Steps to reproduce the behavior, please include where possible:

  • Operation code & usage

see above

  • Target system information

OpenBSD 7.8

  • Example using the @docker connector (helps isolate the problem)

Expected behavior

I expect bsdinit.service(running=True) to behave consistently idempotent across all services.

Meta

  • Include output of pyinfra --support.
❱ pyinfra --support 

    If you are having issues with pyinfra or wish to make feature requests, please
    check out the GitHub issues at https://github.com/Fizzadar/pyinfra/issues .
    When adding an issue, be sure to include the following:

    System: Linux
      Platform: Linux-7.0.10+deb14-amd64-x86_64-with-glibc2.42
      Release: 7.0.10+deb14-amd64
      Machine: x86_64
    pyinfra: v3.9.2
      click: v8.4.1
      distro: v1.9.0
      gevent: v26.5.0
      jinja2: v3.1.6
      packaging: v26.2
      paramiko: v4.0.0
      pydantic: v2.13.4
      python-dateutil: v2.9.0.post0
      typeguard: v4.5.2
      types-paramiko: v4.0.0.20260518
      typing-extensions: v4.15.0
    Executable: /home/aqw/.venvs/pyinfra/bin/pyinfra
    Python: 3.13.14 (CPython, GCC 15.2.0)
  • How was pyinfra installed (source/pip)?
uv pip install pyinfra
  • Include pyinfra-debug.log (if one was created)

none

  • Consider including output with -vv and --debug.

If you would like the output, please let me know. I've reviewed it, and I was unable to find anything informative.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugLabel for all kind of bugs.connectorsConnector issues - builtin integrations with other tools.operationsIssues with operations.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions