Slow unity panel loading during first login

[Moritz Oberhauser]

It takes about 10 to 15 seconds to display the menubar, the unity starter and desktop icons during the first login. It usually took half a second, so this looks like a bug. Right before these show up, a short black frame indicates some component crashed and was restarted. After this delay the performance is fine as usual.

I tried to debug the performance drop during these 10 seconds with top in the terminal, but did not know what to look for. Unsurprisingly most active processes were sysvinit, xorg, compiz and unity, but all about 1% CPU usage at maximum.

First occurance has been about one week ago, it did not happen directly after the fresh installation of the 14.04.1 image .

I don't use proprietary drivers and didn't mess with xorg edgers if I remember correctly. Could be a bug of unity or compiz, too.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xorg 1:7.7+1ubuntu8
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
Uname: Linux 3.13.0-39-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Fri Nov 21 13:37:52 2014
DistUpgraded: Fresh install
DistroCodename: trusty
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Gigabyte Technology Co., Ltd Device [1458:d000]
InstallationDate: Installed on 2014-11-03 (17 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
MachineType: Gigabyte Technology Co., Ltd. To be filled by O.E.M.
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-39-generic.efi.signed root=UUID=b2639ac3-cb2b-47d4-a542-a157679e7b71 ro rootflags=subvol=@ quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/29/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F3
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: Z77N-WIFI
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF3:bd05/29/2013:svnGigabyteTechnologyCo.,Ltd.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnZ77N-WIFI:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To be filled by O.E.M.
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
version.compiz: compiz 1:0.9.11.2+14.04.20140714-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.52-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.1.3-0ubuntu0.2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.3-0ubuntu0.2
version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3.1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.910-0ubuntu1.3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2
xserver.bootTime: Fri Nov 21 13:31:39 2014
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 2266
 vendor SAM
xserver.version: 2:1.15.1-0ubuntu2.1

[Moritz Oberhauser (zomtir)]

If I set my login to automatic, I get very close symptoms to bug #1380050. Screen is black for few seconds and Xorg peaks to 10% CPU usage at that time.

[Moritz Oberhauser (zomtir)]

Found the issue, i had four NTFS partitions auto mounted with ntfs-3g in /etc/fstab. Setting three of them to "noauto" reduced the delay to 2 seconds. I'm quite sure if I remove the last one it's fixed completely, but I need it.

So should I file the bug against fuse / ntfs-3g / another display package or is this inteded?

[Moritz Oberhauser (zomtir)]

I subscribed Elliot Murphy and filed it against fuse as ntfs-3g has no maintainer. Please mark the bug as conformed or invalid. Hope this is the right procedure.

[Moritz Oberhauser (zomtir)]

Seems to be fixed in Vivid Vervid. The underlying reason was that Ubuntu attempted to fix the ntfs partition after it was used by Windows, resulting in a very long mount operation.

Mount times are now fast as usual, either Windows does not break the filesystem anymore or Ubuntu handles it properly/faster.