Service.is_valid always returns invalid because of unrelated issues

オープン
  • 何か問題がありますか？
#689 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

@CarstenGrohmann がすでに取り組んでいます。

2025年4月15日 から。

  • #805 @CarstenGrohmann による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
linux, python
領域
infrastructure, testing

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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 :-)

主要言語
Python
スター
2.5k
フォーク
358
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

pytest-dev/pytest-testinfra のほかの issue

pytest-dev/pytest-testinfra の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。