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 /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 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.
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 translations.
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 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.
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.