service is_running does not work with exit code 4

[martinhoyer]

Error code 4: LSB: "program or service status is unknown" systemd: "no such unit"

I would expect service.is_running() to return False, when service is not available, while like this is causes a crash, as there is run_expect([0, 1, 3]

Would it be possible to add rc 4, at least to SystemdService?

[arossert]

I have the same issue, is there a workaround for this one?

[philpep]

Crash is expected no ? I mean a service which doesn't exists should not be reported as just "not running".

[permanentdaylight]

Crash is expected no ? I mean a service which doesn't exists should not be reported as just "not running".

That makes sense, but the main problem here is the inconsistency in behavior (example of Ubuntu 22 and Ubuntu 24)

$ u22.service('fake').is_running
False

$ u24.service('fake').is_running
AssertionError!

So the painpoint is running the same test against the two distros now requires us to hack the test a bit to account for the same scenario returning separate results.

[pfuntner]

That makes sense, but the main problem here is the inconsistency in behavior (example of Ubuntu 22 and Ubuntu 24) ... So the painpoint is running the same test against the two distros now requires us to hack the test a bit to account for the same scenario returning separate results.

I agree. We have some tooling that deals with a variety of distros (Debian, Alma, etc) and Ubuntu 24 is the only one giving trouble. For the time being, I'm slipping in a class with a few methods such as is_enabled() that calls host.service(server_name).is_enabled but inside a try block which returns False when an exception is raised.

[martinhoyer]

Ubuntu 24 is the only one giving trouble.

I don't think it's just Ubuntu 24 tbh.

https://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

manpage of my systemd-255.12-1.fc40:

EXIT STATUS
       On success, 0 is returned, a non-zero failure code otherwise.

       systemctl uses the return codes defined by LSB, as defined in LSB
       3.0.0[3].

       Table 3. LSB return codes
       ┌───────┬─────────────────────┬─────────────────────┐
       │ Value │ Description in LSB  │ Use in systemd      │
       ├───────┼─────────────────────┼─────────────────────┤
       │ 0     │ "program is running │ unit is active      │
       │       │ or service is OK"   │                     │
       ├───────┼─────────────────────┼─────────────────────┤
       │ 1     │ "program is dead    │ unit not failed     │
       │       │ and /var/run pid    │ (used by is-failed) │
       │       │ file exists"        │                     │
       ├───────┼─────────────────────┼─────────────────────┤
       │ 2     │ "program is dead    │ unused              │
       │       │ and /var/lock lock  │                     │
       │       │ file exists"        │                     │
       ├───────┼─────────────────────┼─────────────────────┤
       │ 3     │ "program is not     │ unit is not active  │
       │       │ running"            │                     │
       ├───────┼─────────────────────┼─────────────────────┤
       │ 4     │ "program or service │ no such unit        │
       │       │ status is unknown"  │                     │
       └───────┴─────────────────────┴─────────────────────┘

[philpep]

Crash is expected no ? I mean a service which doesn't exists should not be reported as just "not running".

That makes sense, but the main problem here is the inconsistency in behavior (example of Ubuntu 22 and Ubuntu 24)

$ u22.service('fake').is_running
False

$ u24.service('fake').is_running
AssertionError!

So the painpoint is running the same test against the two distros now requires us to hack the test a bit to account for the same scenario returning separate results.

What about:

if host.service('fake').exists:
    assert host.service('fake').is_running

?

[ltog]

@philpep

What about:

if host.service('fake').exists:
    assert host.service('fake').is_running

?

That is a helpful workaround!

[CarstenGrohmann]

@philpep: Please close this issue, as it's already fixed with merged PR #773