Teamviewer 8 and 9 Won't Show GUI

[macs]

I am attempting to get TV8 and/or TV9 (I've tried both) to run on OpenSUSE 13.1.  Both version of TV fail to show the GUI when the Teamcenter executable is invoked. I've also tried this with the standalone install of TV9 (the tar.gz package) and I get the same results. Basically, no error message is given, but, the GUI never appears. Furthermore, I've noticed that if I leave the process running long enough (even though the GUI never appears), eventually, the CPU will get slammed to 100% until I manually kill the process.

As I said, this same behavior happens with both the installed version and the standalone version.

A typical command line invocation of the standalone TV9 gives the following:

mike@mike:~/Downloads/teamviewer9> ./teamviewer
Init...
Checking setup...
Launching TeamViewer ...
Starting network process (no daemon)
Network process started (25826)
Launching TeamViewer GUI ...

The startup.log file contains the following:

TeamViewer: 9.0.24147 - TAR
Profile: /home/mike (mike)
Desktop: default
XServer TTY:  7
Distributor ID: openSUSE project
Description:    openSUSE 13.1 (Bottle) (x86_64)
Release:        13.1
Codename:       Bottle
ok
 -
ok

The winlog file contains the following:

ixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" failed to start: 2
fixme:service:scmdatabase_autostart_services Auto-start service L"PlugPlay" failed to start: 2
fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
err:secur32:SECUR32_initSchannelSP TLS library not found, SSL connections will fail
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution
.
err:winspool:add_printer_driver failed with 1722 for L"wineps.drv" (L"Windows NT x86")
fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub!
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (3): stub
fixme:process:SetProcessShutdownParameters (00000100, 00000000): partial stub.
fixme:resource:GetGuiResources (0xffffffff,0): stub
fixme:win:EnumDisplayDevicesW ((null),0,0x33f718,0x00000000), stub!
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x33f3d0,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x33f718,0x00000000), stub!
fixme:console:CONSOLE_DefaultHandler Terminating process 8 on event 0

The Teamviewer9_Logfile.log contains the following:

2013/12/14 22:07:34.796 25826 4148156224 N0   SystemdSessionInfoProvider: systemd-logind service available
2013/12/14 22:07:34.796 25826 4148156224 N0   systemd: updating session info by inotify
2013/12/14 22:07:34.798 25826 4148156224 N0   SystemdSeat: New seat seat0 [path=/org/freedesktop/login1/seat/seat0, activeSession='1', canGraphical=1, canTTY=1, canMultiSession=1]
2013/12/14 22:07:34.799 25826 4148156224 N0!!!DBus: expected property KillProcesses not found!
2013/12/14 22:07:34.799 25826 4148156224 N0!  DBus: expected optional property DefaultControlGroup not found
2013/12/14 22:07:34.800 25826 4148156224 N0!! systemd: failed to fetch seat/session info, session handling disabled (DBus: Error in casting variant)
2013/12/14 22:07:34.801 25826 4148156224 N0   XSocketSessionObserver: watching /tmp/.X11-unix
2013/12/14 22:07:34.809 25826 4148156224 N0!! XSession: No valid authorisation record found for :0 in possible files
2013/12/14 22:07:34.809 25826 4148156224 N0!  XSession: Unable to open XAuthority file ""
2013/12/14 22:07:34.810 25826 4148156224 N0   Starting as network
2013/12/14 22:07:34.812 25826 4148156224 N0   UpdateOnlineState newOnlineValue 0

The only log that shows anything of oddness to me is the Teamviewer9 logfile; the reference to not being able to open the XAuthority file grabs my attention the most but I can't really make sense of what it means, how to resolve it, or if it is actually the item causing the problem.

I've Googled for the odd messages in the log file but I haven't found anything of substance.

Does anyone have any ideas on how to trouble shoot this?

[midixinga]

same here after changing motherboard/cpu/graphics/ram (now asrock h87m pro4 with intel core i5-4570)

teamviewer process takes immediately 100% of one cpu-core and doesnt show the gui

I've tried arch-linux-aur-tv8, arch-lnux-aur-tv9, windows-teamviewer with wine, original teamviewer.tgz -> always the same issue

the only thing, that work, is starting windows-teamviewer-setup Executable (with wine of course) choosing "only start" (no installation)

very strange - it does not depend on desktop-environment

[midixinga]

supplement:
teamviewer 7 works

[BV523]

I couldn't get TeamViewer9 to launch after installing from AUR, also edited  /usr/lib/systemd/system/teamviewerd.service
change
ExecStart = /opt/teamviewer9/tv_bin/teamviewerd -d
to
ExecStart = /opt/teamviewer9/tv_bin/teamviewerd

restarted daemon, would get this:
root@arch-bill /home/bill # systemctl start teamviewerd
Warning: Unit file of teamviewerd.service changed on disk, 'systemctl daemon-reload' recommended.
root@arch-bill /home/bill # systemctl daemon-reload
root@arch-bill /home/bill # systemctl start teamviewerd
root@arch-bill /home/bill #

However, I had been running tv8 without issue for some time in Arch before this, so re-installed teamviewer8 from the AUR and restarted daemon same as above, and tv8 works

[BV523]

This is in regards to Teamviewer9 not able to run on Arch Linux (xfce); re-install Teamviewer8 from the AUR if you were upgrading from 8 to 9, 8 works

[midixinga]

Thank you BV523 - but it doesn't work for me

i've always the same issue - also with tv8 and also with changed start command for the teamviewerd.service

i'm using KDE, but i also tried it with twm

[midixinga]

fyi, maybe a haswell bug, see:
https://aur.archlinux.org/packages/teamviewer/
https://bugs.archlinux.org/task/39597
https://bbs.archlinux.org/viewtopic.php?id=175878

reinstalling modified lib32-glibc (for Arch Linux 64 Bit) from
https://copy.com/qSIobMy1K8aD

solved it for me

[macs]

Midixinga:

Thanks for those links. I saw something about the Haswell issue a few days ago and I'm glad to hear that resolved it for you as that lends credibility to glibc being the issue as to why Teamviewer is not starting.

I looked into a new glibc for my distro (OpenSUSE) but nothing is available yet that addresses this issue. I don't feel confident in picking up glibc compiled for a different distro nor am I entirely keen on recompiling such a heavily used lib in my system but I may have no choice.  

Thanks again!
MACS

[midixinga]

new Linux Version with old Bug: very very

[eusdaiki]

HI Guys,


Im seeing this bug on Fedora 20

2014/04/08 10:16:02.924  7123 4147971904 S0   Starting as daemon
2014/04/08 10:16:02.925  7123 4147971904 S0!! ParseTextfile: Unknown header in settings file: '[[al.conf'
2014/04/08 10:16:02.925  7123 4147971904 S0   UpdateOnlineState newOnlineValue 0
2014/04/08 10:16:02.948  7123 4147971904 S0   Generating new RSA private/public key pair
2014/04/08 10:16:02.975  7123 4147971904 S0   MID: Read from disk failed.
                   
                   
                   
Start:              2014/04/08 10:16:02.975  (UTC-6:00)
Version:            9.0.24147
ID:                 0
Loglevel:           Info (100)
License:            0
Server:             master3.teamviewer.com
IC:                 1234672468
CPU:                Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
CPU extensions:     h9
OS:                 Lx Fedora 20 (Heisen (32-bit)
IP:                 192.168.0.102
MID:                0x00224da659ad_2a24c0b8_d41d8cd98f00b204
MIDv:               0
Proxy-Settings:     Type=1 IP= User=

2014/04/08 10:16:02.976  7123 4147971904 S0   Using IPC-Port 5939
2014/04/08 10:16:02.979  7123 4045404992 S0   Using systemd-logind for suspend/resume monitoring
2014/04/08 10:16:02.979  7123 4147971904 S0   SystemdSessionInfoProvider: systemd-logind service available
2014/04/08 10:16:02.979  7123 4147971904 S0   systemd: updating session info by inotify
2014/04/08 10:16:02.980  7123 4147971904 S0   SystemdSeat: New seat seat0 [path=/org/freedesktop/login1/seat/seat0, activeSession='1', canGraphical=1, canTTY=1, canMultiSession=1]
2014/04/08 10:16:02.980  7123 4147971904 S0!!!DBus: expected property KillProcesses not found!, Errorcode=11
2014/04/08 10:16:02.980  7123 4147971904 S0!  DBus: expected optional property DefaultControlGroup not found
2014/04/08 10:16:02.980  7123 4147971904 S0!! systemd: failed to fetch seat/session info, session handling disabled (DBus: Error in casting variant), Errorcode=11
2014/04/08 10:16:02.981  7123 4147971904 S0   XSocketSessionObserver: watching /tmp/.X11-unix
2014/04/08 10:16:02.999  7123 4147971904 S0   UpdateOnlineState newOnlineValue 0
2014/04/08 10:16:03.003  7123 4147971904 S0   UpdateOnlineState newOnlineValue 0
2014/04/08 10:16:03.003  7123 4147971904 S0   UpdateOnlineState newOnlineValue 0
2014/04/08 10:17:03.001  7123 4024433472 S0   SystemdSessionInfoProvider: systemd-logind service available
2014/04/08 10:17:03.001  7123 4024433472 S0   systemd: updating session info by inotify
2014/04/08 10:17:03.002  7123 4024433472 S0   SystemdSeat: New seat seat0 [path=/org/freedesktop/login1/seat/seat0, activeSession='1', canGraphical=1, canTTY=1, canMultiSession=1]
2014/04/08 10:17:03.002  7123 4024433472 S0!!!DBus: expected property KillProcesses not found!, Errorcode=11
2014/04/08 10:17:03.002  7123 4024433472 S0!  DBus: expected optional property DefaultControlGroup not found
2014/04/08 10:17:03.003  7123 4024433472 S0!! systemd: failed to fetch seat/session info, session handling disabled (DBus: Error in casting variant), Errorcode=11
2014/04/08 10:18:03.004  7123 4024433472 S0   SystemdSessionInfoProvider: systemd-logind service available
2014/04/08 10:18:03.005  7123 4024433472 S0   systemd: updating session info by inotify
2014/04/08 10:18:03.005  7123 4024433472 S0   SystemdSeat: New seat seat0 [path=/org/freedesktop/login1/seat/seat0, activeSession='1', canGraphical=1, canTTY=1, canMultiSession=1]
2014/04/08 10:18:03.006  7123 4024433472 S0!!!DBus: expected property KillProcesses not found!, Errorcode=11
2014/04/08 10:18:03.006  7123 4024433472 S0!  DBus: expected optional property DefaultControlGroup not found
2014/04/08 10:18:03.006  7123 4024433472 S0!! systemd: failed to fetch seat/session info, session handling disabled (DBus: Error in casting variant), Errorcode=11
2014/04/08 10:19:03.007  7123 4024433472 S0   SystemdSessionInfoProvider: systemd-logind service available
2014/04/08 10:19:03.007  7123 4024433472 S0   systemd: updating session info by inotify
2014/04/08 10:19:03.008  7123 4024433472 S0   SystemdSeat: New seat seat0 [path=/org/freedesktop/login1/seat/seat0, activeSession='1', canGraphical=1, canTTY=1, canMultiSession=1]

I've tried reinstalling glibc-devel and glibc-common, restarting the daemon, restarting the service, deleting the config file (to force creation of a new one) installing a full version of wine, running as user, running as sudo...


all with no success.

Any ideas on how to translate the Archlinux solution to Fedora?

thnx!

[Semmelbrösel]

It seems that my debian box is affected as well. I recently upgraded to Jessie (coming from Wheezy) and since then my Teamveiwer won't start (100% CPU, not showing GUI) any more. On Wheezy it worked without any problems.

Just that I understand this correctly: Is this a bug of glibc, teamviewer or even a bug of my intel processor? I've an i5-4570

Greetings
Martin

[Semmelbrösel]

Great - Teamviewer just released a new update. Version 9.0.30203. With the new version my teamviewer works again!

[thesourcehim]

Gui doesn't crash indeed, but I get "Not ready, check connection" message again (Fedora 20 x86_64). Before update connection worked fine. Daemon says "TeamViewer ID:                   
Try restarting the TeamViewer daemon (e.g. teamviewer --daemon restart)". Restarting doesn't help. My network is ok, I can connect to my other computers using web client.

[midixinga]

On my Arch with Haswell CPU it's also working without modified lib32-glibc - finally after months

[macs]

I just got around to trying their newest released version. Indeed, it does seem to now work!