Bug 1410164 - tigervnc-server fails to remove /tmp files if not gracefully shut down
Summary: tigervnc-server fails to remove /tmp files if not gracefully shut down
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tigervnc
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jan Grulich
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1393395
TreeView+ depends on / blocked
 
Reported: 2017-01-04 16:11 UTC by Alex Ladd
Modified: 2017-08-01 20:50 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-08-01 20:50:05 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2000 normal SHIPPED_LIVE Moderate: tigervnc and fltk security, bug fix, and enhancement update 2017-08-01 18:33:08 UTC
Red Hat Knowledge Base (Solution) 2845221 None None None 2017-01-20 23:19 UTC

Description Alex Ladd 2017-01-04 16:11:52 UTC
Description of problem:

If tigervnc server is not gracefully shut down, the files it creates in /tmp and /tmp/.X11-unix/ are not removed. Systemd cannot restart the service until those files are removed manually with the error "Job for vncserver@:2.service failed because a configured resource limit was exceeded. See "systemctl status vncserver@:2.service" and "journalctl -xe" for details."

Also, when systemd is used to attempt to restart, additional files are created in /tmp and /tmp/.X11-unix/ associated with ports that have not been configured to run with the vnc server.


Version-Release number of selected component (if applicable):

tigervnc-server-1.3.1-9.el7
and tigervnc-server-1.3.1-4.el7_2


How reproducible:

use kill -9 on the Xvnc service file, then check /tmp to see if the files have been cleaned up. 

kill -15 seems to clean up the files fine

logging out does not seem to clean up lock files or socket files

rebooting cleans up the .X2 lock file, but not the X2 socket file
both X1 files that were created when X2 failed to start remain


Steps to Reproduce:

# systemctl start vncserver@:2
# systemctl enable vncserver@:2
Created symlink from /etc/systemd/system/multi-user.target.wants/vncserver@:2.service to /etc/systemd/system/vncserver@:2.service.

# ls -la /tmp
-r--r--r--.  1 user user   11 Dec 28 16:20 .X2-lock

# ls -l /tmp/.X11-unix/
total 0
srwxrwxrwx. 1 root  root  0 Dec 28 15:04 X0
srwxrwxrwx. 1 user user 0 Dec 28 16:20 X2

# ps -aux | grep vnc
user    14317  0.1  1.3 219400 25444 ?        Sl   16:19   0:00 /usr/bin/Xvnc :2 -desktop qward72:2 (aladd) -auth /home/aladd/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/aladd/.vnc/passwd -rfbport 5902 -fp catalogue:/etc/X11/fontpath.d -pn
user    14445  0.0  0.2  96792  4092 ?        S    16:20   0:00 /usr/bin/vncconfig -iconic
root     15489  0.0  0.0 112652   972 pts/0    R+   16:22   0:00 grep --color=auto vnc

# kill -15 14317
# ps -aux | grep vnc
root     15570  0.0  0.0 112648   972 pts/0    S+   16:25   0:00 grep --color=auto vnc

# systemctl start vncserver@:2
# ps -aux | grep vnc
user    15678  1.8  1.3 219444 25604 ?        Sl   16:25   0:00 /usr/bin/Xvnc :2 -desktop qward72:2 (aladd) -auth /home/aladd/.Xauthority -geometry 1024x768 -rfbwait 30000 -rfbauth /home/aladd/.vnc/passwd -rfbport 5902 -fp catalogue:/etc/X11/fontpath.d -pn
user    15738  0.0  0.2  96792  4092 ?        S    16:25   0:00 /usr/bin/vncconfig -iconic
root     16523  0.0  0.0 112652   972 pts/0    S+   16:25   0:00 grep --color=auto vnc

# kill -9 15678
# ps -aux | grep vnc
root     16642  0.0  0.0 112648   972 pts/0    S+   16:26   0:00 grep --color=auto vnc

# systemctl start vncserver@:2
Job for vncserver@:2.service failed because a configured resource limit was exceeded. See "systemctl status vncserver@:2.service" and "journalctl -xe" for details.

# ls -la /tmp
-r--r--r--.  1 user user   11 Dec 28 16:27 .X1-lock
-r--r--r--.  1 user user   11 Dec 28 16:25 .X2-lock

# ls -l /tmp/.X11-unix/
total 0
srwxrwxrwx. 1 root  root  0 Dec 28 15:04 X0
srwxrwxrwx. 1 user user 0 Dec 28 16:27 X1
srwxrwxrwx. 1 user user 0 Dec 28 16:25 X2



Actual results:

Until the lock files are manually removed from /tmp after vncserver quits unexpectedly, vncserver will not restart. 


Expected results:

vnc should clean up files in /tmp associated with the port of the service file that quits unexpectedly



Additional info:

Comment 8 errata-xmlrpc 2017-08-01 20:50:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2000


Note You need to log in before you can comment on or make changes to this bug.