Teamviewer 13 & Debian Stable 9.2 — no GUI

just updated from Teamviewer 12 (which worked fine at the time*) via the 64-bit deb provided from the download page.

Terminal output …Terminal output …However no GUI materializes. In fact nothing at all happens. There is no tray icon, no window, no process shown via ps (other than teamviewrd). I do not know if the server portion is working (ie whether I'd be able to log into the computer) since I uninstalled & purged Teamviewer 12 before installing 13—and thus am not able to log in to my Teamviwer Account. or otherwise get the ID for this machine in order to attempt a connection.

Debian 9.2 | kernel 4.9 | no Desktop Environment, just a window manager (JWM) running on top of X. Willing to provide logs if instructed how to do so. Please advise.

*

Spoiler

though I did have a very similar issue with the GUI in version 12 back in April. I opened ticket #3093852. I received a request from Gilberto for logs, which I sent and that is the end of my own documentation on the issue. I do not recall what (if anything) I did to rectify the situation, it is very probable that simply updating teamviewer resolved the issue for me at that time.

_________
Updated to add info (I just found out about 'teamviewer --info' while reading around on the forums. So here it is, in case it is useful:12-05-2017_05-37-33pm.png

Best Answer

Answers

  • Same with me here. Except for that I get a window frame with not repainted window content. I use debian 9.2 with KDE plasmashell desktop.

  • J_Reis
    J_Reis Posts: 14

    Support was kind enough to engage with me via email. Since there's at least one other person with a similar issue and perhaps more to come, I'm posting that exchange here to bump the thread.
    No suggestion yet for a solution, but at least someone is taking a second look. Kudos to the TV team for that!

     

    Spoiler
    Hi Justin,

    first, I cannot promise that we get this resolved if it is just a JWM issue.
    At the moment we can not invest a lot of time to such niche DEs.

    Still, you could try if it works with a different Desktop, showing whether it is actually related to it.
    Also, you can run 'teamviewer ziplog' (preferrably as root) and attach the resulting file.
    Please indicate timestamps when you:
    - logged in to JWM (and teamviewer was installed)
    - tried to start the gui manually inside of JWM
    - restarted the daemon 'teamviewer daemon restart' while inside of JWM

    Btw, you might find 'teamviewer ps' helpful :)

    Best regards,
    Daniel
    -----------------------
    Hey Daniel, thanks for following up! Logs are attached. I wasn't certain if you intended for me to reinstall TV, so I lazily chose not to. To be clear, TV13 was installed (since yesterday), I rebooted the system and then did the following:
    System up (startx > start jwm): ~10:01:20
    attempt manual start teamviewer GUI: ~10:03:44
    teamviewer daemon restart: ~10:04:51

    Regarding niche configurations. I understand what you're trying to say. Broadly, I'm pleased anytime a company is willing to provide Linux compatibility, much less support of any kind. I also recognize the fact that I'm a non-paying user. So my expectations for support are tempered and I very much do appreciate your getting back with me.

    That said (and forgive me if I'm brow-beating you with what you already know), but the whole point of modularity in the design of the graphic stack is that the choice of how to handle say, window decorations & keyboard shortcuts (ie a window manager) should have no effect on the design of applications themselves—which, in turn, have complete control over (and are responsible for) the contents of their windows. Put another way, I'm regularly running dozens of applications: some FOSS, some commercial; some massive projects with hundreds of devs and some hobbyist one-man efforts. None of them are spending any dev effort to specifically support JWM or any other window manager. They work because they are supported by xorg/gtk/qt whatever, not because someone included anything to make them compatible with jwm or xmonad or i3 or whatever.

    My guess is that TV depends on something that major DEs also depend on and so TV is working on Gnome or KDE because that package happens to already be present on the system. If that is the case, then TV is working in these cases out of sheer dumb luck. That would be a packaging issue for TV (not properly specifying dependencies) and helping me identify it (and getting it fixed) should help TV run properly on many systems, not just those few who happen to be running JWM.

    Regards,

    Justin R.


    -----------------

    email.jpg

    ~ Primum vivere deinde philosophari. ~
    In necessariis unitas, in dubiis libertas, in omnibus caritas.
    Justin.J.Reis@gmail.com   |   STARavian.org 


  • My problem seemed to be a long initialization the first time I run the TV 13 on my system. I reinstalled it couple of times, with downgrade to 12 and back to 13. Then suddenly I realized that the TV13 window was open and initialized. Since then it starts quickly and is usable.

  • J_Reis
    J_Reis Posts: 14

    Had a bit of time to try and sort this out and made some progress. The issue is resolved for me by installing Xfce4 and rebooting.

    Specifically I installed Xfce4 via apt, then logged out of X and from the terminal into Xfce via 'exec startxfce4' in xinitrc. At this point Teamviewer still did not work (same behavior as before, no gui, no error, output ends at 'Launching TeamViewer GUI ...'). After rebooting, which dropped brought me to a display manager (as Xfce installed lightdm automatically). Logging into Xfce, Teamviewer now works as expected. Indeed, even loggin out of Xfce and back into jwm (via the display manager) and Teamviewer works in jwm as well. Uninstalling Xfce and associated packages breaks Teamviewer once again, returning its behavior to its original state (no gui shown).

    A few possibilities come to mind:

    1.) One of the packages pulled by Xfce fixes the issue both in Xfce and in jwm, but only after a reboot (does that narrow down which one?).

    2.) Logging in through a display manager rather that using 'startx' from terminal fixes the issue. Maybe due to some kind of difference in what kind of session/secure session is launched? I'm not nearly familiar enough with the nitty-gritty of how these sorts of things work to know, but it seems like it might be something like that.

    Next step would be to reinstall Xfce and mess around with loggin in via lighdm vs terminal to narrow it down. If it works both ways I guess I start installing packages one at a time until I find the combination that works, but maybe there's enough clues in all this that someone smarter than I can identify the issue and save me the trouble!

    Here's a list of the packages added to my system when installing Xfce:

    Spoiler
    desktop-base desktop-file-utils gtk2-engines-xfce gvfs gvfs-common gvfs-daemons gvfs-libs libkeybinder-3.0-0 liblightdm-gobject-1-0 libnotify-bin libthunarx-2-0 libtumbler-1-0 libxfce4panel-2.0-4 libxfce4ui-2-0 libxfce4ui-utils libxklavier16 light-locker lightdm lightdm-gtk-greeter tango-icon-theme thunar thunar-data thunar-volman tumbler tumbler-common xfce4 xfce4-appfinder xfce4-notifyd xfce4-pulseaudio-plugin xfce4-session xfce4-settings xfdesktop4 xfdesktop4-data xfwm4
  • Hello,

    simililar problem (TV12 was working fine):

    debian 9:  tar.xz version

    I see in log:

    2017/12/19 18:10:24.451 14909 140681964977344 G SysSessionInfoManager: observing sessions from logind is marked as reliable
    2017/12/19 18:10:24.451 14909 140681964977344 G SysSessionInfoManager: Session Information provided by VT [priority: 2]
    2017/12/19 18:10:24.453 14909 140681964977344 G SysSessionInfoManager: own session cache set to '4294967295'
    2017/12/19 18:10:24.454 14909 140681964977344 G Running on Qt 5.7.1
    2017/12/19 18:10:24.483 14909 140681964977344 G Initialised XRandR extension 1.5 (base=89 error=147)
    2017/12/19 18:10:24.561 14909 140681964977344 G MonitorInfo: [XRandR 1.2] CRTC DVI-I-1 1920x1080@60Hz [3840, 0, 5760, 1080] - 1
    2017/12/19 18:10:24.561 14909 140681964977344 G MonitorInfo: [XRandR 1.2] CRTC HDMI-0 1920x1080@60Hz [0, 0, 1920, 1080] - 1
    2017/12/19 18:10:24.561 14909 140681964977344 G MonitorInfo: [XRandR 1.2] CRTC DP-0 1920x1200@60Hz [1920, 0, 3840, 1200] - 1
    2017/12/19 18:10:24.561 14909 140681964977344 G MonitorInfo: [XRandR 1.2] CRTC 3 has no outputs
    2017/12/19 18:10:24.561 14909 140681964977344 G Virtual Desktop [0, 0, 5760, 1200]
    2017/12/19 18:10:24.561 14909 140681964977344 G!! MonitorInfo: WorkingArea: Property error 14 (0), Errorcode=2
    2017/12/19 18:10:24.601 14909 140681964977344 G InterProcessBase::SecureNetwork created
    2017/12/19 18:10:24.602 14909 140681964977344 G AutoLogin::Login: enabled: 1
    2017/12/19 18:10:24.603 14909 140681964977344 G WindowsSessionStateManager(0x283e020) state 0
    2017/12/19 18:10:24.603 14909 140681964977344 G!!!Own session could not be resolved, unable to startup, Errorcode=2
    2017/12/19 18:10:24.604 14909 140681964977344 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 5 failed with error 2, Errorcode=2
    2017/12/19 18:10:24.604 14909 140681964977344 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 6 failed with error 2, Errorcode=2
    2017/12/19 18:10:24.605 14909 140681964977344 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 9 failed with error 2, Errorcode=2
    2017/12/19 18:10:24.605 14909 140681964977344 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 10 failed with error 2, Errorcode=2
    2017/12/19 18:10:24.606 14909 140681964977344 G interprocessbase::SecureNetwork destroyed
    2017/12/19 18:10:24.611 14909 140681964977344 G Shutting down System DBus

    I hope it helps.

  • DamienCassou
    DamienCassou Posts: 6 ✭✭
    I have exactly the same problem (with EXWM) and I hope we get a solution soon.
  • login───bash───sudo───lightdm─┬─Xorg───3*[{Xorg}]
    │ ├─lightdm─┬─sh─┬─ssh-agent
    │ │ │ └─xfce4-session

    TeamViewer 14.0.14470 (DEB) 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 GNU/Linux Debian GNU/Linux buster/sid

    no GUI either, any suggesations ? thanks.

  • swec
    swec Posts: 2

    A have (od had?) very similar issue with Teamviewer 14.1.? and Debian 9.6. It started without GUI.

    But today i downloaded version Teamviewer 14.1.9025 and it suddenly works fine.

    Last update on my Debian i did one or two weeks ago, i have installed all 32 bit and 64bit libraries, because i need use some 32bit binary applications and i am using desktop LXDE.

    Fact is, after this problems, a am not able trust TeamViewer enough and still considering replacement for daily work. But at least it works somehow. Maybe, at first, Teamviewer should report much more info in console what is happening and what failed. It is really hard guess where problem can be without informations.

  • Can confirm the issue still exists in 14.5.5691 (debian and tar.xz download as well).

    I'm using nodm with LXDE on Linux Mint Debian 3.

    Installing a display manager is a workaround for the problem. SDDM did the trick for me. (Although technically it needs to find the session manager (lxsession), not the dm)