Bugzilla – Bug 7159
Profile chooser/session startup windows aren't shown during and after Openbox builds fontconfig cache
Last modified: 2018-05-07 10:42:19
You need to
before you can comment on or make changes to this bug.
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
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
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
> /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 /firstname.lastname@example.org/10/Xauthority -desktop email@example.com@dhcp-253-180.lkpg.cendio.se -rfbport 5910 -rfbauth /firstname.lastname@example.org/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 /email@example.com/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.
> (_NET_CLIENT_LIST or _WIN_CLIENT_LIST)
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
> $ 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
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.
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).
So, our client suffers from the same problem:
1. install 4.9.0rc2 tlclient on ubuntu/debian
2. rm -r ~/.cache/fontconfig
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:
https://intranet.lkpg.cendio.se/ThinLinc/WorkFlow/Release updated with
instructions on how to regenerate the images after applying updated
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.
Created an attachment (id=860) [details]
Border on splash upon session start
Commit r33254 introduced a border draw which doesn't look that sexy within a
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.
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.
Release notes looks good. Closing.