Teamviewer GUI not starting when running level 3 + startx
Hi,
I am using Slackware latest, updated. Teamviewer works fine when using runlevel 4, but the GUI won't start when using runlevel 3 + startx. Any idea where to start checking/editing? Thank you, Kind regards! |
On Debian, I'd look into /etc/rc3.d and compare what's in there to /etc/rc4.d. (And on my system, they're the same; Slackware does things different here.)
Why do you want to start X in RC 3? |
Quote:
thank you for your reply. I checked and I have nothing in rc3.d / rc4.d, only the rc.4 script in /etc/rc.d. Because Linux is very new for me I like to start in runlevel 3 and practice (create/copy/move files, directories, use tar/makepkg/upgradepkg for different software that I use). And teamviewr GUI not staring is a little annoying since I use this a lot. Kind regards! |
Quote:
And figure out what the default for runlevel 3 is. I guess there's more in /usr/lib/rc.d or some such? In any case, the logic is clear: "level 4" does something that "level 3 + startx" does not do, thus enabling teamviewer to start. I suspect either XDG autostart or dbus magic. |
Most of my not starting in X things is because $DISPLAY is not set.
$ echo $DISPLAY $ export DISPLAY=":0"; ./run_my_app But I use multiple users, mostly so I don't have to keep logging in and out of various web based things. I just su users and launch a browser from that user. Requires weaker X permissions $(xhost local:), so all users can use X. Namely those users that did NOT start X. Depending on distro and distro version, the DISPLAY variable may or may NOT be set for those other users. You can also set the :# at the time that you launch X with startx $ startx -- :0 -dpi 100 -depth 24 -to 10 -retro -nolisten tcp -layout MultiHead HTH, YMMV |
Hi guys,
I got this from teamviewer logs : runlevel 4 : LogindSessionInfo: New session LogindSessionInfo [id=1 user=sb state=user active=1 reliable=1 infoId=2212294583] [path=/org/freedesktop/login1/session/_31 TTY= seat=seat0 display=:0 vtnr=7 owner=[SysUser: sb [uid=1000, gid=100 home=/home/sb gecos=Dname shell=/bin/bash]] idle=0(0) active=1 type=x11 class=user state=active timestamp=1596640311688399 service=sddm defaultCG= leader=1360 audit=1 remote=0 rHost= rUser= killProc=0] SysSessionInfoManager::SessionAdded: adding session XSession: 0 [SysSession 2212294583 [type=88 vt=7 tty= pseudotty=0 info=1 id=1 user=sb state=user active=1 reliable=1]] SysSessionInfoManager::SessionAdded: adding session SysSession 3510599056 [type=70 vt=7 tty=/dev/tty0 pseudotty=0 info=1 id=/dev/fb0 user=root state=greeter active=0 reliable=1] runlevel 3 + startx LogindSessionInfo: New session LogindSessionInfo [id=1 user=sb state=user active=1 reliable=1 infoId=2212294583] [path=/org/freedesktop/login1/session/_31 TTY=tty1 seat=seat0 display= vtnr=1 owner=[SysUser: sb [uid=1000, gid=100 home=/home/sb gecos=name shell=/bin/bash]] idle=1(1596637920940000) active=1 type=tty class=user state=active timestamp=1596637829447255 service=login defaultCG= leader=1186 audit=1 remote=0 rHost= rUser= killProc=0] no adding XSession line SysSessionInfoManager::SessionAdded: adding session SysSession 3510599056 [type=70 vt=1 tty=/dev/tty0 pseudotty=0 info=1 id=/dev/fb0 user=root state=greeter active=0 reliable=1] All the differences are bold+italic, and the service=sddm/login is also colored, I think this could be the main reason, after searching and reading..and so on. Maybe this can help someone to figure this out. Thank you, Kind regards |
I might be more helpful to run strace and see what it's trying to open( that it is/is not finding. It might be something as simple and common and pulseaudio. A session manager shouldn't be an app killer. It mostly remembers what things were running and where you had them last time you ran them. Not a requirement for most know what they're doing applications. Although some odd audio apps require networking to be functional and even a FQDN IP to be assigned in /etc/hosts. Or they wont launch/function.
Perhaps check if the $PATH and such varies between options. $ echo $PATH |
So it does start with level 3 + startx! How do you start it?
Have you checked what the difference is between "level 4" and "level 3 + startx"? I suspect dbus magic. I have this in my ~/.xinitrc: Code:
if [ -d /etc/X11/xinit/xinitrc.d ] |
Hi guys,
it seems it has something to do with this : with elogind as the session/seat manager instead of ConsoleKit2, you’ll see some new behaviour. A quite obvious change: if you run ‘startx’ or ‘startkwayland’ at the console, you won’t see a VT (virtual terminal) switch. In the past, your console TTY would usually be tty1 but your graphical session would start on tty7 and you would automatically be switched from tty1 to tty7. This is no longer true – the graphical session will re-use your console TTY. SDDM is still starting on tty7 but only because I make it do so via its configuration file. from https://alien.slackbook.org/blog/ I maybe saying something stupid but : from what I understand, with startx, sddm starts on tty7, but the graphical session will start on tty1 (or other tty# - depending where startx is executed). And maybe teamviewer is looking only for VT7. I didn't find a way to make startx, xinitrc or other config file to switch from tty1 to tty7. Any thoughts? Kind regards! |
You can disable sddm.
$ sudo systemctl disable sddm Assuming systemd. Not sure how startkwayland works. Just know that wayland is a protocol, not an X of sorts. So abandon ship on all previous wm's, no matter how small/simple they were. And with things like sway, an alternative i3 for wayland, screen blanking and such is wm/de dependent and probably won't be implemented initially. And that alone keeps me on X11 / xwayland. But my use case is cwm + playlist until it pauses after 40 minutes and the screen blanks AKA IRL SLEEP. |
Did you follow these instructions? https://slackbuilds.org/repository/1...rk/teamviewer/
Maybe ask a moderator to move this thread to the Slackware sub-forum. |
Quote:
Yes, all the time, as explained. |
All times are GMT -5. The time now is 07:55 PM. |