Service.is_valid always returns invalid because of unrelated issues

Abierto
  • ¿Algo no está bien?
#689 2 comentarios 0 reacciones 0 asignados Ver en GitHub

@CarstenGrohmann ya está trabajando en esto.

Desde el 15/4/2025.

  • #805 de @CarstenGrohmann — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
linux, python
Área
infrastructure, testing

Línea de trabajo

Start in testinfra/modules/service.py and inspect the service.is_valid path that runs systemd-analyze verify; reproduce the reported stderr behavior with the example unit output. Done means validation no longer fails on unrelated systemd messages while still detecting the service's own invalid-unit message, with coverage for both cases.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

On a system with some systemd issues, the outcome of host.service('myservice').is_valid is always False, even if my service is actually good.

On further investigation the original pull request to add this https://github.com/pytest-dev/pytest-testinfra/pull/265 added a check to make sure STDOUT and STDERR were emtpy, as the call to systemd-analyze verify %s always returns 0. However, in come cases, STDERR can contain unrelated information which trips up the comparison.

As an example, I have a deliberate typo in my service unit. The output of systemd-analyze verify myservice.service is as follows (all on STDERR):

snap-core18-2632.mount: Unit is bound to inactive unit dev-loop1.device. Stopping, too.
snap-snapd-18357.mount: Unit is bound to inactive unit dev-loop5.device. Stopping, too.
snap-snapd-17883.mount: Unit is bound to inactive unit dev-loop4.device. Stopping, too.
snap-core20-1828.mount: Unit is bound to inactive unit dev-loop7.device. Stopping, too.
/lib/systemd/system/myservice.service:17: Missing '=', ignoring line.

If I correct the typo, then the last line of this output goes away, but the others remain (actually, on my system the others seem to change every time I run the verify, but I always get at least a couple of lines out of it).

I'm not sure what's up with my system that it should do this (or why systemd would behave this way) but I'm wondering what the best solution to the testinfra problem is. I'm thinking a sort of "grep" of the output for myservice.service would suffice? Something like:

stderr = "".join(filter(lambda x: name in x, cmd.stderr.split()))

Or in place in the function in testinfra/modules/service.py (also taking the opportunity to add some output to explain the reason for the failure):

   @property
    def is_valid(self):
        # systemd-analyze requires a full path.
        if self.name.endswith(".service"):
            name = self.name
        else:
            name = self.name + ".service"
        cmd = self.run("systemd-analyze verify %s", name)
        # A bad unit file still returns a rc of 0, so check the
        # stdout for anything.  Nothing means no warns/errors.
        # Docs at https://www.freedesktop.org/software/systemd/man/systemd
        # -analyze.html#Examples%20for%20verify
        stderr = "".join(filter(lambda x: name in x, cmd.stderr.split()))
        assert (cmd.stdout, stderr) == ("", ""), "service %s is not valid (see 'systemd-analyze verify %s' for details)" % (name, name)
        return True

Happy to hear other suggestions or ideas etc :-)

Lenguaje dominante
Python
Estrellas
2.5k
Forks
358
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pytest-dev/pytest-testinfra

Todos los issues de pytest-dev/pytest-testinfra

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.