By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 1745

Summary:	Running vncserver from TightVNC causes Trinity to exit
Product:	TDE	Reporter:	Darrell <darrella>
Component:	other (any)	Assignee:	Timothy Pearson <kb9vqf>
Status:	RESOLVED NOTOURPROBLEM
Severity:	normal	CC:	bugwatch, darrella, kb9vqf
Priority:	P5
Version:	R14.0.0 [Trinity]
Hardware:	Other
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:

Description Darrell 2013-11-29 11:11:06 CST

TightVNC 1.3.10. Trinity R14.

Open konsole or the mini cli.

Run:

vncserver -geometry XXXXxYYYY :1

Where XXXXxYYYY is the preferred screen resolution. For example, with a laptop:

vncserver -geometry 1280x800 :1

After a few seconds, Trinity crashes.

Disabling the KDED TDE Internet Daemon, which controls ports 5800/5900 and might conflict with TightVNC, makes no difference.

I tested the same in KDE4 and xfce and the desktops did not crash or terminate.

Comment 1 Darrell 2013-12-01 19:55:01 CST

tigervnc 1.1.0 also crashes the desktop.

With both, in run level 3 I am dumped to the command line. With init 4, I'm unsure, but looks like the X server is restarted and I'm returned to TDM.

Comment 2 Timothy Pearson 2013-12-01 22:44:25 CST

This might be caused by a bad XRandR implementation in the mentioned VNC servers.  Is there a crash message in dmesg or similar?

Comment 3 Darrell 2013-12-02 13:40:27 CST

Nothing in the system logs, but the xsession-error logs provide a clue. I think what is happening is the way both vncservers function. They both create a VNC portal on X screen :1 (or any screen other than :0). That creates an xsession-error log for my screen :1. In that log I see many errors about not finding various X resources.

I use an unorthodox startup scripting process because I want to toggle quickly between different desktop environments for comparative testing. Various scripts and environment variable containers have to be sourced correctly.

At the moment I believe the problem is the default xstartup script created by vncserver does not account for my unorthodox setup. When the various X resources are not found, which does not happen in my regular setup because my scripts handle everything, the X server dies. When the X server dies, all X sessions die, not just :1.

Another clue is I now realize Trinity is not crashing but exiting gracefully because the xsession-error log for :0 shows the same messages as a normal session exit.

The fact that the other desktops don't terminate likely is because I don't use any special scripts for those environments. Just the standard xinit scripts.

I will leave the report open and find time later to investigate fully. More than likely not a Trinity problem.

Comment 4 Darrell 2013-12-02 13:45:40 CST

On further reflection, I'm convinced the problem is my script setup and not Trinity. Should that not be the case I will reopen the report.