Bug 1224253 - [Build 20240514] WSL does not have procps installed
Summary: [Build 20240514] WSL does not have procps installed
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: WSL (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: QE Containers and Public Cloud team qa-c
URL: https://openqa.opensuse.org/tests/418...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-15 07:18 UTC by Dominique Leuenberger
Modified: 2024-05-16 13:25 UTC (History)
2 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique Leuenberger 2024-05-15 07:18:52 UTC
## Observation

It is debatable if procps should be pre-installed; the openQA test relies on it for now (if you decide it should not be preinstalled, we will have to get the tests adjusted). If preinstalled is fine, then procps should be listed in the kiwi file as explicit dependency

in the past, zypper just happened to pull in procps - which was an old remaining dep from ZMD times. Spring cleanup happened now.

openQA test in scenario opensuse-Tumbleweed-WSL-x86_64-wsl2-systemd@win10_64bit fails in
[enable_systemd](https://openqa.opensuse.org/tests/4188285/modules/enable_systemd/steps/14)

## Test suite description
Enable and test systemd in WSL


## Reproducible

Fails since (at least) Build [20240514](https://openqa.opensuse.org/tests/4188285) (current job)


## Expected result

Last good: [20240513](https://openqa.opensuse.org/tests/4186367) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=WSL&machine=win10_64bit&test=wsl2-systemd&version=Tumbleweed)
Comment 1 Scott Bradnick 2024-05-15 13:38:38 UTC
I don't have any fundamental issue w/ adding procps to the kiwi definition, but I don't know that using "ps" to test systemd setup is all that bullet-proof.

I'd like to see something like "systemctl --user status" instead checking for "State: Running".
Comment 2 Fabian Vogt 2024-05-16 07:11:41 UTC
(In reply to Scott Bradnick from comment #1)
> I don't have any fundamental issue w/ adding procps to the kiwi definition,
> but I don't know that using "ps" to test systemd setup is all that
> bullet-proof.
> 
> I'd like to see something like "systemctl --user status" instead checking
> for "State: Running".

It does that as well. It just verifies that pid 1 is /sbin/ init by using ps 1 currently.

IMO procps is something that users expect to be there (ps, top, free) and should be in the image in any case.
Comment 3 Scott Bradnick 2024-05-16 13:25:23 UTC
(In reply to Fabian Vogt from comment #2)
> ...
> It does that as well. It just verifies that pid 1 is /sbin/ init by using ps
> 1 currently.

I'm not sure I find _that_ method very useful, nor the list-unit-files example - but I suppose there isn't one singular way to determine if systemd has been enabled (successfully).

> IMO procps is something that users expect to be there (ps, top, free) and
> should be in the image in any case.

I certainly agree here, just unfortunate some change happens somewhere else and it has far-reaching impact; but a simple solution (I'm not arguing against) and I appreciate you and Dominique pushing it through.