For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!
Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.
Oracle Policy Automation August 2015 (12.2.0) is now available for download from Oracle® Software Delivery Cloud (http://edelivery.oracle.com/) and the Oracle Technology Network (OTN) (http://www.oracle.com/technetwork/apps-tech/policy-automation/downloads/index.html)
Updated products:
( http://documentation.custhelp.com/euf/assets/devdocs/august2015/PolicyAutomation/en/Default.htm#Guides/Getting_Started/Whats_New.htm )
Thanks, I'll ask the development team to investigate.
I think the following is related:
https://github.com/systemd/systemd/issues/8085
https://github.com/systemd/systemd/commit/db256aab13d8a89d583ecd2bacf0aca87c66effc
In case of the vncserver service unit and OS release 8, the PID file (or variable) was removed.
EL7: /usr/lib/systemd/system/vncserver\@.service
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/sbin/runuser -l <USER> -c "/usr/bin/vncserver %i"
PIDFile=/home/<USER>/.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
EL8: /usr/lib/systemd/user/vncserver@.service
ExecStart=/usr/bin/vncserver %i
ExecStop=/usr/bin/vncserver -kill %i
The entire service file seems to be Red Hat-specific, as you can see here: https://git.centos.org/rpms/tigervnc/blob/c7/f/SOURCES/vncserver.service.
Unfortunately you cannot view the history for the file because there is an error - the new CentOS/RHEL source repository uses Pagure, and it breaks quite a lot.
Edit: By Red Hat-specific I didn't necessarily mean written by Red Hat; I meant that it is provided as a whole file in the repo instead of a patch to an existing file.
I am having the same problem with OEL 7.7
# systemctl start vncserver@:3.service
Job for vncserver@:3.service failed because a configured resource limit was exceeded. See "systemctl status vncserver@:3.service" and "journalctl -xe" for details.
# systemctl status vncserver@:3.service
...
Sep 11 14:30:10 mcsdboralnx5.esri.com systemd[1]: Starting Remote desktop service (VNC)...
Sep 11 14:30:13 mcsdboralnx5.esri.com systemd[1]: New main PID 20733 does not belong to service, and PID file is not owned by root. Refusing.
I opened a ticket with RedHat and they pointed me to the bugzilla bug below.
Once it is OEL 7.7 OS the RedHat Support closed my case. I decided to open a SR to notify Oracle Support as well.
The vncserver daemon is still active and can accept connections, but it cannot be managed by systemd.
------
https://bugzilla.redhat.com/show_bug.cgi?id=1747191
"Bug 1747191 - tigervnc service via unit file fails with PID file error"
Actual results: Service fails with the error "New main PID $PIDNUM does not belong to service, and PID file is not owned by root.
Refusing." The VNC daemon is still active and can accept connections; however, it cannot be managed by systemd at this point.
Expected results: Service runs normally without issue.
Additional info: This appears to be the same bug as bug 1583159 filed against Fedora 27. While replacement unit files were provided in that bug, by themselves they don't appear to work completely in RHEL 7.7; the daemons start and systemd reads it as started, but attempting to log in via GDM fails. There may be additional work to be done.
-----
I hope this helps.
Thanks,
Marcelo Marques
Technical Manager, OCP
Esri - www.esri.com
Did a little more digging as I just stepped in this same issue on tigervnc-server 1.8.0 when I upgrade to centos 7.7 earlier today.
I think we may be looking in the wrong place. Output from my journalctl -xe shows this:
-- The start-up result is done.
Oct 03 17:48:08 berne runuser[23923]: pam_limits(runuser-l:session): invalid line 'ulimit -u 50000' - skipped <<<<<<<<=================
Oct 03 17:48:08 berne runuser[23923]: pam_unix(runuser-l:session): session opened for user virt by (uid=0)
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:1 is taken because of /tmp/.X1-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:1
Oct 03 17:48:08 berne runuser[23923]: A VNC server is already running as :1
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:2 is taken because of /tmp/.X2-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:2
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:3 is taken because of /tmp/.X3-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:3
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:4 is taken because of /tmp/.X4-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:4
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:5 is taken because of /tmp/.X5-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:5
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:6 is taken because of /tmp/.X6-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:6
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:7 is taken because of /tmp/.X7-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:7
Oct 03 17:48:08 berne runuser[23923]: Warning: berne:8 is taken because of /tmp/.X8-lock
Oct 03 17:48:08 berne runuser[23923]: Remove this file if there is no X server berne:8
Oct 03 17:48:11 berne runuser[23923]: New 'berne:10 (virt)' desktop is berne:10
Oct 03 17:48:11 berne runuser[23923]: Starting applications specified in /home/virt/.vnc/xstartup
Oct 03 17:48:11 berne runuser[23923]: Log file is /home/virt/.vnc/berne:10.log
Oct 03 17:48:11 berne runuser[23923]: pam_unix(runuser-l:session): session closed for user virt
Oct 03 17:48:11 berne systemd[1]: Can't open PID file /run/virt.vnc.berne:1.pid (yet?) after start: No such file or directory
Oct 03 17:48:11 berne systemd[1]: Failed to start Remote desktop service (VNC).
-- Subject: Unit vncserver@:1.service has failed
I'd say you are experiencing a different problem. The error you are seeing occurs when you start the Xvnc server using a port that is already in use. Your Xvnc or TigerVNC server could be freezing or crashing for several reasons. You need to quit the previous Xvnc process before you an start a new process using the same configuration. The -lock files contain the process ID of the Xvnc process. When you stop the Xvnc process, the corresponding -lock file is usually removed.
vncpilot handles the situation as following, for example:
[root@vm7051 tmp]# ls -al .*-lock
ls: cannot access .*-lock: No such file or directory
[root@vm7051 tmp]# vncpilot -c -size=1280x800
[root@vm7051 tmp]# cat .X95-lock
2538
[root@vm7051 tmp]# ps -ef | grep 2538
vnc-410 2538 1 0 18:36 ? 00:00:00 /usr/bin/Xvnc :95 -auth /home/vnc-410/.Xauthority -depth 16 -desktop vm7051.example.com:95 (vnc-410) -fp catalogue:/etc/X11/fontpath.d -geometry 1280x800 -pn -rfbauth /home/vnc-410/.vnc/passwd -rfbport 5995 -rfbwait 30000 -nevershared -localhost -SecurityTypes=vncauth
VNCpilot 1.0.2. Copyright (c) 2018, 2019 Dude! @ Oracle Community.
Free under the GNU General Public License. See vncpilot --help for info.
%vncpilot-E-169, TCP port 5995 already in use.
[root@vm7051 tmp]# vncpilot -d
You are correct WRT shutting down previous process. As systemd apparently no longer controls it, I manually killed it and wiped locks (/tmp/.X*lock).
The current lock points to the process:
[root@berne virt]# cat /tmp/.X14-lock
32739
[root@berne virt]# ps -ef|grep 32739
root 1540 32269 0 20:15 pts/0 00:00:00 grep --color=auto 32739
virt 32739 1 0 20:10 ? 00:00:00 /usr/bin/Xvnc :14 -geometry 1600x1024 -auth /home/virt/.Xauthority -desktop berne:14 (virt) -fp catalogue:/etc/X11/fontpath.d -pn -rfbauth /home/virt/.vnc/passwd -rfbport 5914 -rfbwait 30000 -Log *:stderr:100
Noting that VNC is running on :14 and not on the expected :1 or :2 (I have two VNC services), I quickly adjusted the port before my F/W mapping and was able to successfully access my box.
I suspect there is no problem with the pid files as they are all present:
[root@berne virt]# ls -ltr .vnc/*
-rw-rw-r--. 1 virt virt 1008 Jan 29 2018 .vnc/berne:2.log
-rw-r--r--. 1 virt virt 330 Jan 29 2018 .vnc/config
-rw-------. 1 virt virt 8 Jul 19 2018 .vnc/passwd
-rwxr-xr-x. 1 virt virt 950 Jul 19 2018 .vnc/xstartup
-rw-rw-r-- 1 virt virt 1740 Oct 3 17:11 .vnc/berne:1.log
-rw-rw-r-- 1 virt virt 6 Oct 3 17:16 .vnc/berne:4.pid
-rw-rw-r-- 1 virt virt 1740 Oct 3 17:21 .vnc/berne:4.log
-rw-rw-r-- 1 virt virt 6 Oct 3 17:39 .vnc/berne:6.pid
-rw-rw-r-- 1 virt virt 6 Oct 3 17:39 .vnc/berne:7.pid
-rw-rw-r-- 1 virt virt 1740 Oct 3 17:44 .vnc/berne:6.log
-rw-rw-r-- 1 virt virt 1740 Oct 3 17:45 .vnc/berne:7.log
-rw-rw-r-- 1 virt virt 6 Oct 3 17:45 .vnc/berne:8.pid
-rw-rw-r-- 1 virt virt 1986 Oct 3 17:47 .vnc/berne:8.log
-rw-rw-r-- 1 virt virt 6 Oct 3 17:47 .vnc/berne:9.pid
-rw-rw-r-- 1 virt virt 6 Oct 3 17:48 .vnc/berne:10.pid
-rw-rw-r-- 1 virt virt 2845 Oct 3 17:53 .vnc/berne:10.log
-rw-rw-r-- 1 virt virt 2753 Oct 3 17:53 .vnc/berne:9.log
-rw-rw-r-- 1 virt virt 6 Oct 3 17:53 .vnc/berne:11.pid
-rw-rw-r-- 1 virt virt 2757 Oct 3 20:00 .vnc/berne:11.log
-rw-rw-r-- 1 virt virt 6 Oct 3 20:01 .vnc/berne:12.pid
-rw-rw-r-- 1 virt virt 2078 Oct 3 20:02 .vnc/berne:12.log
-rw-rw-r-- 1 virt virt 310 Oct 3 20:02 .vnc/berne:13.log
-rw-rw-r-- 1 virt virt 6 Oct 3 20:10 .vnc/berne:14.pid
-rw-rw-r-- 1 virt virt 974 Oct 3 20:10 .vnc/berne:14.log
which makes no sense as I had clearly set the PIDFile to be created elsewhere:
[root@berne virt]# grep PID /etc/systemd/system/vncserver@\:1.service
# PIDFile=/home/<USER>/.vnc/%H%i.pid)
#PIDFile=/home/virt/.vnc/%H%i.pid
PIDFile=/run/virt.vnc.%H%i.pid
and had reloaded systemctl with no result.
I think I finally understand the root symptom that is causing this weird PID issue for tigervnc.
I am seeing that everytime I bounce the service from systemctl, I get the next display number instantiated in the .vnc directory:
[root@berne .vnc]# ls -ltr
total 28
-rw-r--r--. 1 virt virt 330 Jan 29 2018 config
-rw-------. 1 virt virt 8 Jul 19 2018 passwd
-rwxr-xr-x. 1 virt virt 950 Jul 19 2018 xstartup
-rw-rw-r-- 1 virt virt 5 Oct 3 21:00 berne:17.pid
-rw-rw-r-- 1 virt virt 11587 Oct 3 21:10 berne:17.log
yet, the service still believes it should find the display number as specified in the service naming, a 1 here.
[root@berne .vnc]# !syst:p
systemctl start vncserver@:1
[root@berne .vnc]# systemctl -l status vncserver@:1
● vncserver@:1.service - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/vncserver@:1.service; enabled; vendor preset: disabled)
Active: failed (Result: resources) since Thu 2019-10-03 21:00:55 EDT; 10min ago
Process: 8647 ExecStart=/usr/sbin/runuser -l virt -c /usr/bin/vncserver %i -geometry 1800x900 -Log '*:stderr:100' (code=exited, status=0/SUCCESS)
Process: 8589 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
and issues its beef when it can't find that pid as it some how is the next display number, 17 here.
Oct 03 21:00:52 berne systemd[1]: Starting Remote desktop service (VNC)...
Oct 03 21:00:55 berne systemd[1]: Can't open PID file /home/virt/.vnc/berne:1.pid (yet?) after start: No such file or directory
Oct 03 21:00:55 berne systemd[1]: Failed to start Remote desktop service (VNC).
Oct 03 21:00:55 berne systemd[1]: Unit vncserver@:1.service entered failed state.
Oct 03 21:00:55 berne systemd[1]: vncserver@:1.service failed.
I guess I can try reverting the systemd rpm back to the last one under an intact centos 7.6 box and see if this headache goes away. But I believe this is the root cause, systemd is monotonically receiving the next display number from the service naming and passing this to the vnc startup scripts.
This is the root problem:
To start or enable the service, specify the display number directly in the command. The file configured above works as a template, in which %i is substituted with the display number by systemd.
%i
I have also just confirmed that wiping the sockets under /tmp/.X11-unix will prevent the increasing display number:
[root@berne .vnc]# ls -ltr /tmp/.X11-unix
total 0
srwxrwxrwx 1 root root 0 Oct 3 21:00 X0
srwxrwxrwx 1 virt virt 0 Oct 3 21:40 X1
[root@berne .vnc]# lsof /tmp/.X11-unix
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/25584/gvfs
Output information may be incomplete.
[root@berne .vnc]# lsof /tmp/.X11-unix/X?
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
X 8687 root 6u unix 0xffff9465562a3400 0t0 469090 /tmp/.X11-unix/X0
Xvnc 13401 virt 8u unix 0xffff9464fc771000 0t0 580849 /tmp/.X11-unix/X1
But even having created the correct display number:
[root@berne .vnc]# ps -ef|grep vnc
virt 13401 1 0 21:40 ? 00:00:00 /usr/bin/Xvnc :1 -geometry 1600x1024 -auth /home/virt/.Xauthority -desktop berne:1 (virt) -fp catalogue:/etc/X11/fontpath.d -pn -rfbauth /home/virt/.vnc/passwd -rfbport 5901 -rfbwait 30000 -Log *:stderr:100
The status is upset at not finding the PID due to ownership now:
Active: failed (Result: resources) since Thu 2019-10-03 21:40:11 EDT; 11s ago
Process: 13370 ExecStart=/usr/sbin/runuser -l virt -c /usr/bin/vncserver %i -geometry 1800x900 -Log '*:stderr:100' (code=exited, status=0/SUCCESS)
Process: 13364 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
Oct 03 21:40:08 berne systemd[1]: Starting Remote desktop service (VNC)...
Oct 03 21:40:11 berne systemd[1]: New main PID 13401 does not belong to service, and PID file is not owned by root. Refusing.
Oct 03 21:40:11 berne systemd[1]: Failed to start Remote desktop service (VNC).
Oct 03 21:40:11 berne systemd[1]: Unit vncserver@:1.service entered failed state.
Oct 03 21:40:11 berne systemd[1]: vncserver@:1.service failed.
and obviously there is no pid file and I can still connect with no problem:
total 20
-rw-rw-r-- 1 virt virt 6093 Oct 3 21:47 berne:1.log
Hello all. What worked for me in 7.7 was to modify ExecStart in my systemd service file, which was created from the default template (/usr/lib/systemd/system/vncserver@.service), to:
I also added to the [Service] section:
User=<YOUR_VNC_USER>
The root cause seems to be that the upstream vendor hardened systemd security (https://access.redhat.com/errata/RHSA-2019:2091) as a result of a discovered vulnerability (https://access.redhat.com/security/cve/cve-2018-16888). All this affected the ability to execute the tigervnc-server binary as non-root using the runuser command.
Hope this helps someone. Cheers.
I guess that depends on what you wish to accomplish, but for remote access you will probably want some security and allow access only via SSH tunneling and also use VNC authentication.
For example adding -localhost -SecurityTypes=vncauth
Also unless you have Gnome installed, you will need some additional software.
To make statement made by 'user8372473' more clear, your vncserver-$USER@.service file should look like below
===================================
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
User=<USER>
WorkingDirectory=/home/<USER>
# Clean any existing files in /tmp/.X11-unix environment
ExecStart=/usr/bin/vncserver %i -geometry 1600x900
[Install]
WantedBy=multi-user.target
Instead of older way of using 'runuser'/'runas'/'su -c', let Systemd run the service under user which should own the service.
This can work!! add: User=<USER>
alter: ExecStart=/bin/sh -c "/usr/bin/vncserver %i"