Bug 7159 - Profile chooser/session startup windows aren't shown during and after Openbox builds fontconfig cache
Summary: Profile chooser/session startup windows aren't shown during and after Openbox...
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.9.0
Assignee: Peter Åstrand
Keywords: hean01_tester, relnotes
Depends on:
Reported: 2018-04-23 14:16 CEST by Karl Mikaelsson
Modified: 2018-05-07 10:42 CEST (History)
3 users (show)

See Also:
Acceptance Criteria:

Border on splash upon session start (34.73 KB, image/png)
2018-05-07 10:36 CEST, Henrik Andersson

Description Karl Mikaelsson cendio 2018-04-23 14:16:19 CEST
As seen on:

 - Ubuntu 16.04 LTS (x86_64) with ThinLinc 4.9.0rc1, local user accounts
 - Debian 9 (i386) with ThinLinc 4.9.0rc2, user accounts from LAB AD

When the user logs in to ThinLinc and does not have a fontconfig cache at 
~/.cache/fontconfig, the session startup feedback and profile chooser windows are not shown to the user. This can happen when the user does not have a home directory.

There are two phases of this problem:

Phase 1: Openbox initialization

There is a long delay before anything at all happens in the session. After being started by the tl-run-xstartup.d script, Openbox tries to build a font cache, which can be seen by strace:ing the openbox process. On both systems that
exhibit this problem, this takes longer than 30 seconds. After 30 seconds of trying to communicate with openbox, tl-run-xstartup.d declares that openbox has not started and continues with the session startup. This message can be seen in xinit.log:

> /opt/thinlinc/etc/xsession: Timeout waiting for window manager to start

Phase 2: Waiting for tl-run-xstartup-feedback/tl-select-profile

After the timeout, the normal session startup processes are launched in order. Once the session ends up where the user is supposed to select their profile, it waits for the user. From xinit.log again:

> Running /opt/thinlinc/etc/xstartup.d/20-tl-select-profile.sh (Choosing a profile)

At this point, no windows are shown to the user. The relevant processes for showing windows has been started:

> cendio@+  7048  7045  0 13:03 ?        00:00:00 /opt/thinlinc/libexec/Xvnc :10 -depth 24 -geometry 1280x1024 -fp catalogue:/etc/X11/fontpath.d,/usr/share/fonts/X11/misc,/usr/share/fonts/X11/Type1,/usr/share/fonts/truetype -auth /var/opt/thinlinc/sessions/cendio@lab.lkpg.cendio.se/10/Xauthority -desktop cendio@lab.lkpg.cendio.se@dhcp-253-180.lkpg.cendio.se -rfbport 5910 -rfbauth /var/opt/thinlinc/sessions/cendio@lab.lkpg.cendio.se/10/vncpasswd -QueryConnect -br -nolisten tcp -localhost -verbose 3
> cendio@+  7088  7071 85 13:03 ?        00:00:37 /opt/thinlinc/libexec/openbox
> cendio@+  7241  7071  2 13:04 ?        00:00:00 python-thinlinc /opt/thinlinc/libexec/tl-run-xstartup-feedback /var/opt/thinlinc/sessions/cendio@lab.lkpg.cendio.se/10/tl-run-xstartup.7071
> cendio@+  7298  7297  1 13:04 ?        00:00:00 python-thinlinc /opt/thinlinc/libexec/tl-select-profile

While openbox is still creating a fontconfig cache, running wmctrl to get a list of windows will fail:

> $ wmctrl -l
> Cannot get client list properties.
> $

After openbox is done with the cache, running wmctrl -l inside the session produces no output - in other words, there are no windows inside the session yet.

> $ wmctrl -l
> $

The session will stay in this state at least overnight, unless interacted with. Once you click inside the session or press a key on the keyboard, the missing windows shows up. Running wmctrl -l at this point shows two windows:

> $ wmctrl -l
> 0x00400003  0 dhcp-253-180.lkpg.cendio.se Starting ThinLinc Session
> 0x00a00003  0 dhcp-253-180.lkpg.cendio.se ThinLinc Profile Chooser
> $

Erasing ~/.cache/fontconfig is enough to trigger the problem again for new logins.
Comment 1 Karl Mikaelsson cendio 2018-04-24 14:32:50 CEST
I'm not seeing this with ThinLinc 4.8.1 on the same Debian 9 machine.

There is a short delay (~5 seconds) until any windows are shown during which openbox consuming 100% CPU, but nowhere close to 45 seconds. Also no problems with hidden/non-existing windows during this time.
Comment 2 Pierre Ossman cendio 2018-04-24 15:38:46 CEST
The extra delay is caused by an upgraded freetype (which we did on bug 5160). Downgrading just freetype causes the problem to go away.

However it's not necessarily a bug. The new version of freetype finds more fonts, so it could simply be support for more font formats. I can see support for color emoji fonts and truetype collection files being added.

I also compared with the system fc-cache and it executes in roughly the same time (tested on both Fedora 27 and Ubuntu 16.04).
Comment 3 Samuel Mannehed cendio 2018-04-25 16:16:35 CEST
So, our client suffers from the same problem:

1. install 4.9.0rc2 tlclient on ubuntu/debian
2. rm -r ~/.cache/fontconfig
3. tlclient

This will just like the openbox-startup take ~40 seconds.

I also tested Google Chrome, which suffers from the exact same problem. Applications like gedit does NOT suffer from this problem.

It seems like non-repo firefox builds also have the issue:
Comment 15 Samuel Mannehed cendio 2018-05-03 15:17:26 CEST
https://intranet.lkpg.cendio.se/ThinLinc/WorkFlow/Release updated with instructions on how to regenerate the images after applying updated translations.
Comment 23 Pierre Ossman cendio 2018-05-07 10:05:34 CEST
We've now sorted out given the user some feedback as to what is happening during this long delay. However we'd really like this delay to not happen at all. Bug 7169 and bug 7170 have been added to improve things further.
Comment 24 Henrik Andersson cendio 2018-05-07 10:36:45 CEST
Created attachment 860 [details]
Border on splash upon session start

Commit r33254 introduced a border draw which doesn't look that sexy within a session startup.
Comment 25 Henrik Andersson cendio 2018-05-07 10:39:00 CEST
Verified client functionality with and without fontcache using ThinLinc 4.9.0 build 5774 on arch X86_64 and armhf client.

Works as expected, splash shows up when font cache is rebuilding and is not shown when the cache exists.
Comment 26 Henrik Andersson cendio 2018-05-07 10:40:44 CEST
Verified that a session start using ThinLinc 4.9.0 build 5774 shows a splash screen if there is no font cache built. Also verified that the splash is not show if font cache is available.
Comment 27 Henrik Andersson cendio 2018-05-07 10:42:19 CEST
Release notes looks good. Closing.

Note You need to log in before you can comment on or make changes to this bug.