Bug 380495 - Freezes during login process
Summary: Freezes during login process
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (show other bugs)
Version: 5.8.6
Platform: Debian testing Linux
: NOR grave
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-03 09:07 UTC by Nobuhiro Iwamatsu
Modified: 2019-06-19 08:50 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
a patch (1.07 KB, patch)
2017-06-03 09:07 UTC, Nobuhiro Iwamatsu
Details
an example app to illustrate the hang situation (293 bytes, text/x-csrc)
2017-06-10 15:04 UTC, YOSHINO Yoshihito
Details
an example launcher script for the app to illustrate the hang situation (52 bytes, application/x-shellscript)
2017-06-10 15:05 UTC, YOSHINO Yoshihito
Details
gzip'd file containing the execution of startkde from my .xinitrc file. (7.29 KB, application/gzip)
2019-03-15 23:30 UTC, George R. Goffe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nobuhiro Iwamatsu 2017-06-03 09:07:33 UTC
Created attachment 105862 [details]
a patch

Login processing stops with ksplashqml.
This causes problems in the uim Japanese input environment of Debian stretch (Debian 9).

When Mr.Yoshino investigated this problem, he and I thought that this is ksplashqml's problem, not uim and other software.

An upstream commit
https://cgit.kde.org/plasma-workspace.git/commit/?id=56d2c15b9acb9c4b57398b281685807c3191f622
has caused this problem.

x-session-manag,133,kdetest /usr/bin/x-session-manager
  ├─(ksplashqml,232)
  ├─ssh-agent,191 /usr/bin/im-launch x-session-manager
  ├─uim-toolbar,220
  │   ├─{llvmpipe-0},235
  │   ├─{llvmpipe-1},236
  │   ├─{llvmpipe-2},237
  │   └─{llvmpipe-3},238
  └─uim-xim,219
ksplashqml,233,kdetest Breeze --pid
  ├─mozc_server,239
  │   ├─{IPCServer},244
  │   ├─{QueueTimer},240
  │   ├─{QueueTimer},243
  │   └─{WatchDog},242
  ├─uim-candwin-qt5,245 -v
  │   ├─{QDBusConnection},249
  │   └─{QXcbEventReader},248
  ├─{QDBusConnection},255
  ├─{QQmlThread},254
  ├─{QXcbEventReader},234
  ├─{llvmpipe-0},250
  ├─{llvmpipe-1},251
  ├─{llvmpipe-2},252
  └─{llvmpipe-3},253

# strace -f -p 133
strace: Process 133 attached
read(3, ^Cstrace: Process 133 detached
 <detached ...>

It looks like the parent process (133), x-session-manager (startkde
script), is waiting for the stdout of the ksplashqml process (232),
but which is now defunct. Its child process(es) may be writing to the
same fd.

# ls -l /proc/133/fd/3
lr-x------ 1 kdetest kdetest 64 May 31 05:13 /proc/133/fd/3 -> pipe:[88694]

The direct child of the ksplashqml process (233), the splash screen daemon,
closes the file descriptor at ksplash/ksplashqml/main.cpp:97.

# ls -l /proc/233/fd/1
ls: cannot access '/proc/233/fd/1': No such file or directory

One of the children of the process (239), mozc_server, is holding the fd:

# ls -l /proc/239/fd/1
l-wx------ 1 kdetest kdetest 64 May 31 05:14 /proc/239/fd/1 -> pipe:[88694]

So the startkde process has finished reading the pid number string from
the now-defunct process, but is still waiting for another write(s) until
the (shared) fd has been closed.

This mozc_server process has been started during uim-qt5
(a QPlatformInputContext) startup in the SplashApp
initialization phase at ksplash/ksplashqml/main.cpp:92.

Due to the upstream commit the splash screen daemon does not close file
descriptors before the SplashApp initialization, thus its subprocess
shares the fds.

The commit log states Wayland initialization of this daemon needs the
channels. While it may require open file descriptors 0, 1 or 2,
no one should expect the process to talk to the parent through the
descriptors, since the splash screen is a daemon.

An attached patch reverts the commit and redirects the file descriptors
to /dev/null.

MR.Yoshino created a patch which revise this problem.
Could you check this patch?
Comment 1 YOSHINO Yoshihito 2017-06-10 15:04:12 UTC
Created attachment 106034 [details]
an example app to illustrate the hang situation
Comment 2 YOSHINO Yoshihito 2017-06-10 15:05:45 UTC
Created attachment 106035 [details]
an example launcher script for the app to illustrate the hang situation
Comment 3 YOSHINO Yoshihito 2017-06-10 15:07:13 UTC
Here is some additional info for more clarity:

Actually the attached patch just changes ksplashqml to simulate pre-5.3.90 behavior, where it does not emit log anywhere (because it had closed all the file descriptors). The only difference is that SplashApp's file descriptors 0, 1 and 2 are open during its initialization phase.

The ksplashqml's caller is /usr/bin/startkde (symlinked by /usr/bin/x-session-manager in a fresh Debian KDE desktop installation), at line 187:
> ksplash_pid=`ksplashqml "${ksplashrc_ksplash_theme}" --pid`
The caller hangs at this point. As in the previous comment it is reading file descriptor 3, which is apparently the stdout of the ksplashqml process, and is waiting forever, which means the pipe is not closed and is empty. The pipe's file descriptor (writer side) is shared through fork. A small main.c and small caller script attached are a minimal example of the situation.
The caller expects that ksplashqml with "--pid" option emit the pid string of its forked process and immediately exit. In reality the ksplashqml process emits the string, but its forked process also holds the pipe and does not close. Thus it hangs. The forked process must not write anything to the pipe, otherwise the caller reads it after the (expected) pid string. So in order to only fix the problem closing (replacing) stdout should suffice.

ksplashqml splash app is a qt5 QGuiApplication, which by default loads QPlatformInputContext (input method) plugins. This is why ksplashqml launches an input method system.
Comment 4 David Edmundson 2017-06-14 00:30:49 UTC
‎[01:15] ‎<‎yyoshino_‎>‎ d_ed: actually I do not figure out the problem on wayland in pre-5.3.90 - On my machine startplasmacompositor seems to work well both with or without this patch


I'm a bit lost. Do we think this patch needed or not?

---

There is another (possibly simpler?) way to solve this. We could background immediately and then replace all the kill $ksplash_pid with kquitapp5 and the DBus name.
Comment 5 YOSHINO Yoshihito 2017-06-17 06:56:54 UTC
(In reply to David Edmundson from comment #4)
> ‎[01:15] ‎<‎yyoshino_‎>‎ d_ed: actually I do not figure out the problem on
> wayland in pre-5.3.90 - On my machine startplasmacompositor seems to work
> well both with or without this patch
> 
> 
> I'm a bit lost. Do we think this patch needed or not?

Yes, the patch is needed. Sorry I have mistyped, to clarify: On my X environment - startkde works well when the patch is applied. On my wayland envionment - startplasmacompositor works even without the patch due to another reason, but is not that good - not fully working. Because uim (an input method system I'm using) is currently broken on wayland, its daemon process crashes on startup and ksplash does not hang but the input method does not function.

On my wayland environment I could not reproduce the original (pre-5.3.95) problem on wayland the commit https://cgit.kde.org/plasma-workspace.git/commit/?id=56d2c15b9acb9c4b57398b281685807c3191f622 has tried to fix.

> There is another (possibly simpler?) way to solve this. We could background
> immediately and then replace all the kill $ksplash_pid with kquitapp5 and
> the DBus name.

I would use the dbus quit interface, while I don't know at first glance why it does not work on my machine, with a following error:
> Error: org.freedesktop.DBus.Error.UnknownObject
> No such object path '/MainApplication'
Comment 6 George R. Goffe 2019-03-15 23:30:31 UTC
Created attachment 118832 [details]
gzip'd file containing the execution of startkde from my .xinitrc file.

Hi,

I think I have this same problem with a Fedora Core 31 (rawhide) system. The system is freshly installed and has several rounds of "normal" package upgrades.

I have my run level set to 3, a text mode login. After login I issue a startx command which uses my .xinitrc config file which contains " /usr/bin/bash -xv /usr/bin/startkde". Startkde just never ends. I have included output of this .xinitrc script.
Comment 7 George R. Goffe 2019-03-16 00:10:42 UTC
I forgot to indicate "my" level of ksplashqml... so here it is: 

plasma-workspace-5.15.3-1.fc31.x86_64
Comment 8 David Edmundson 2019-03-18 13:13:08 UTC
>from my .xinitrc file.


Not using a Display Manager is unsupported. 90% of the time it is a user setup issue, and this is not a support forum.

Please use SDDM and reopen if you still have an issue. If that works, use "env" to compare what's different.
Comment 9 YOSHINO Yoshihito 2019-03-18 15:20:56 UTC
Hello,

I am the original reporter of this bug. This bug is still applicable to recent ksplashqml. Debian-based systems bundle the attached patch and work fine.
I would really appreciate it if the patch would be included upstream.
Comment 10 George R. Goffe 2019-03-20 01:44:03 UTC
Dave,

Unsupported? Are you kidding me? I've been using KDE for over 10 years and have not had this problem.

I have in fact tried SDDM and still have the problem.

George...
Comment 11 George R. Goffe 2019-03-26 03:26:50 UTC
This problem still seems to exist. Is anyone working this bug?

George...
Comment 12 David Edmundson 2019-06-19 08:50:55 UTC
Git commit 5bc35571901c029fade2ccbcdef191cb3ce01150 by David Edmundson.
Committed on 19/06/2019 at 08:49.
Pushed by davidedmundson into branch 'master'.

Simplify KSplash

Summary:
Forking and printing a PID gains nothing.

The new startplasma script tracks the process used to start ksplash
itself.

Test Plan:
Logged in, saw a splash
Ran the test from systemsettings, saw a splash

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: apol, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D21890

M  +0    -30   ksplash/ksplashqml/main.cpp

https://commits.kde.org/plasma-workspace/5bc35571901c029fade2ccbcdef191cb3ce01150