Bug 1212983 - [Build 20230703] sddm - user session is not always on the VT it is expected to be on
Summary: [Build 20230703] sddm - user session is not always on the VT it is expected t...
Status: NEW
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma) (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: E-Mail List
QA Contact: E-mail List
URL: https://openqa.opensuse.org/tests/340...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-04 13:04 UTC by Dominique Leuenberger
Modified: 2023-07-05 17:20 UTC (History)
1 user (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 2023-07-04 13:04:43 UTC
## Observation

This is a bit surprising, btonly happens in one of the openQA tests, but on that one reliably.

The test expects the KDE session on VT2 (where is moved with sddm 0.20) - but for some reason after login out, and back in, the session is not where it is supposed to be.

Most other openQA tests for KDE/Plasma seem to get this right though


openQA test in scenario opensuse-Tumbleweed-NET-x86_64-zdup_tw2twnext_kde@64bit-3G fails in
[xterm](https://openqa.opensuse.org/tests/3405380/modules/xterm/steps/3)

## Test suite description
EXCLUDE_MODULES=opensuse_welcome added as it is required for non TW zdup


## Reproducible

Fails since (at least) Build [20230703](https://openqa.opensuse.org/tests/3402838)


## Expected result

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


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=NET&machine=64bit-3G&test=zdup_tw2twnext_kde&version=Tumbleweed)
Comment 1 Fabian Vogt 2023-07-05 17:20:51 UTC
I was able to reproduce this once in several (~5?) tries in a VM.

According to fuser, Xorg is the only user of the tty while the session is running. The "-novtswitch" option is not used, so when Xorg stops, it switches back to whatever VT was previously active (in this case tty1 or tty6) before it dies. Only after it dies, sddm allocates a new VT which should pretty much always be the previous one.

Probably a race condition somewhere.