and what the hell do you think is that below? i have my own systemd unit for a decade working and some random update in F32 breaks it? -------------------- Sep 27 17:25:32 srv-rhsoft systemd[1]: Failed to start VNC Server. Sep 27 17:27:11 srv-rhsoft systemd[1]: Started VNC Server. Sep 27 17:27:11 srv-rhsoft vncserver[1156145]: vncserver has been replaced by a systemd unit. Sep 27 17:27:11 srv-rhsoft vncserver[1156145]: Please read /usr/share/doc/tigervnc/HOWTO.md for more information. Sep 27 17:27:12 srv-rhsoft systemd[1]: Stopped VNC Server. -------------------- [root@srv-rhsoft:~]$ cat /etc/systemd/system/vnc.service # see ~/.vnc/xstartup for window-manager [Unit] Description=VNC Server After=network-up.service Requires=network-online.target network-up.service [Service] ExecStart=/usr/bin/vncserver :1 -fg -geometry 2100x1300 -depth 24 -fp /usr/share/X11/fonts/misc -quiet Group=harry User=harry UMask=0027 Environment=XDG_RUNTIME_DIR=/run/vnc-xdg_runtime_dir RuntimeDirectory=vnc-xdg_runtime_dir RuntimeDirectoryMode=700 # StandardOutput=null Restart=always RestartSec=1 Type=simple ProtectSystem=full ReadOnlyPaths=-/var/lib/rpm ReadWritePaths=-/etc/mtab ReadWritePaths=-/etc/mtab.fuselock ReadWritePaths=-/etc/vmware ReadWritePaths=-/usr/local/Zend InaccessiblePaths=-/boot InaccessiblePaths=-/efi InaccessiblePaths=-/root CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_AUDIT_WRITE CAP_MKNOD CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SETGID CAP_SETPCAP CAP_SETUID CAP_SYSLOG CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_PTRACE CAP_SYS_RAWIO CAP_SYS_TIME CAP_SYS_TTY_CONFIG RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_NETLINK AF_UNIX SystemCallFilter=~@clock @cpu-emulation @reboot @swap @obsolete SystemCallArchitectures=native LockPersonality=yes NoNewPrivileges=yes PrivateDevices=yes ProtectControlGroups=yes ProtectHostname=yes ProtectKernelModules=yes ProtectKernelTunables=yes RemoveIPC=yes[root@srv-rhsoft:~]$ cat /etc/systemd/system/vnc.service # see ~/.vnc/xstartup for window-manager [Unit] Description=VNC Server After=network-up.service Requires=network-online.target network-up.service [Service] ExecStart=/usr/bin/vncserver :1 -fg -geometry 2100x1300 -depth 24 -fp /usr/share/X11/fonts/misc -quiet Group=harry User=harry UMask=0027 Environment=XDG_RUNTIME_DIR=/run/vnc-xdg_runtime_dir RuntimeDirectory=vnc-xdg_runtime_dir RuntimeDirectoryMode=700 # StandardOutput=null Restart=always RestartSec=1 Type=simple ProtectSystem=full ReadOnlyPaths=-/var/lib/rpm ReadWritePaths=-/etc/mtab ReadWritePaths=-/etc/mtab.fuselock ReadWritePaths=-/etc/vmware ReadWritePaths=-/usr/local/Zend InaccessiblePaths=-/boot InaccessiblePaths=-/efi InaccessiblePaths=-/root CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_AUDIT_WRITE CAP_MKNOD CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SETGID CAP_SETPCAP CAP_SETUID CAP_SYSLOG CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_PTRACE CAP_SYS_RAWIO CAP_SYS_TIME CAP_SYS_TTY_CONFIG RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_NETLINK AF_UNIX SystemCallFilter=~@clock @cpu-emulation @reboot @swap @obsolete SystemCallArchitectures=native LockPersonality=yes NoNewPrivileges=yes PrivateDevices=yes ProtectControlGroups=yes ProtectHostname=yes ProtectKernelModules=yes ProtectKernelTunables=yes RemoveIPC=yes RestrictSUIDSGID=yes MemoryDenyWriteExecute=no PrivateNetwork=no PrivateTmp=no PrivateUsers=no ProtectHome=no RestrictNamespaces=no RestrictRealtime=no [Install] WantedBy=multi-user.target RestrictSUIDSGID=yes MemoryDenyWriteExecute=no PrivateNetwork=no PrivateTmp=no PrivateUsers=no ProtectHome=no RestrictNamespaces=no RestrictRealtime=no [Install] WantedBy=multi-user.target
besides that it is a joke throwing out such a major breakeage in the middle of a stable release "/usr/lib/systemd/system/vncserver@.service:39: PIDFile= references a path below legacy directory /var/run/, updating /var/run/vncsession-:1.pid → /run/vncsession-:1.pid" confrims how careless and sloppy you act to begin with > # Limitations > You will not be able to start a Tigervnc server for a user who is already > logged into a graphical session are you fucking kidding me? i want my for 10 years working vnc-session with openbox no matte rif the user is logged in into KDE back and the guy who is miles away from hoem for days which is using vnc-over-ssh regulary too
This is upstream decision and solution so please stop with your rant or go to complain somewhere else. (In reply to Harald Reindl from comment #1) > besides that it is a joke throwing out such a major breakeage in the middle > of a stable release "/usr/lib/systemd/system/vncserver@.service:39: PIDFile= > references a path below legacy directory /var/run/, updating > /var/run/vncsession-:1.pid → /run/vncsession-:1.pid" confrims how careless > and sloppy you act to begin with You are free to report this to upstream or propose a fix. > > # Limitations > > You will not be able to start a Tigervnc server for a user who is already > > logged into a graphical session > > are you fucking kidding me? > > i want my for 10 years working vnc-session with openbox no matte rif the > user is logged in into KDE back and the guy who is miles away from hoem for > days which is using vnc-over-ssh regulary too This will most likely work for your openbox session, the reason why this has been mentioned is that going now through systemd with the session being properly configured, the desktop might require a dbus session running which already will be running if the user is logged in graphically. GNOME for example will fail to start, but this is not Tigervnc fault.
> This is upstream decision upstream came with a gun and forced you to push 1.11 to F32? why do you *violate* Fedora policies and push such breaking changes in the middle of a stable release? why don't you read https://github.com/TigerVNC/tigervnc/releases and realize that "vncserver has gotten a major redesign to be compatible with modern distributions" tells you not to push it to Fdora GA releases and instesad go trough the change process so that users upgrading to F34 are aware *before* the upgrade > you are free to report this to upstream or propose a fix what do you need proposed? open the file and replace "/var/run/" with "/run/" and the next time just read your system logs after "systemctl daemon-reload" so that you face obvious issues at your own
https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases A major version number reflects a more-or-less stable set of features and functionality. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience
Package maintainers MUST: Avoid Major version updates, ABI breakage or API changes if at all possible. Avoid changing the user experience if at all possible. Avoid updates that are trivial or don't affect any Fedora users.
(In reply to Harald Reindl from comment #5) > Package maintainers MUST: > > Avoid Major version updates, ABI breakage or API changes if at all > possible. There is no API/ABI change. It's a major change, yes it is, but we have been doing same for Qt or KDE for example. > Avoid changing the user experience if at all possible. It does change user experience, but it should be a positive change, because they now have working systemd support out of the box, which has been broken for very long time. > Avoid updates that are trivial or don't affect any Fedora users. I should have maybe avoid pushing this to Fedora 32, but I still believe this change is worth it. It makes Tigervnc to work much reliably. > > why don't you read https://github.com/TigerVNC/tigervnc/releases and realize > that "vncserver has gotten a major redesign to be compatible with modern > distributions" tells you not to push it to Fdora GA releases and instesad go > trough the change process so that users upgrading to F34 are aware *before* > the upgrade That's exactly what made me to push it to even a stable release, to finally make Tigervnc work reliably with systemd and SElinux. > > you are free to report this to upstream or propose a fix > > what do you need proposed? > > open the file and replace "/var/run/" with "/run/" and the next time just > read your system logs after "systemctl daemon-reload" so that you face > obvious issues at your own And I'm supposed to do exactly what you say? You are free to do it yourself and submit a pull request. I'm not here to fulfill all your wishes. And btw. you can still use /usr/libexec/vncserver same way as before, it won't just accept configuration through the command line, but you have to configure it in /etc/tigervnc/.
> I should have maybe avoid pushing this to Fedora 32 yes > to finally make Tigervnc work reliably with systemd and SElinux yeah, be beeing the *only* package on a full featured Plasma system with all sorts of servers and software pull selinux dependencies > And I'm supposed to do exactly what you say? no, you are supposed to notice and fix such issues at your own as part of your maintaining work > you can still use /usr/libexec/vncserver same way as before, it won't just accept configuration through the command line frankly i gave up with all of that stuff, copied the old wrapper to /usr/local/bin and fixed it so that it don't seek Xvnc because i didn't manage to get a working vncserver within one hour on sunday evening starting just what is told in @/.vnc/xstartup as i am at vacation and the other guy just needed a working remote solution as the last 10 years *now*
FEDORA-2020-98137c59f8 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-98137c59f8
Old vncserver has been backported for Fedora 32 and Fedora 33. Change to /run instead of /var/run has been pushed to upstream for review and will be backported to Fedora once it gets merged.
FEDORA-2020-98137c59f8 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-98137c59f8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-98137c59f8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
The command I have been using for years "vncserver -geometry 1024x768 :2" still doesn't work with that new update. I get a message about it failing to start Xvnc possibly because of a font server problem, then it dies with: Fatal server error: (EE) Unrecognized option: -session I attempted to get the systemd service to work, but I was running into selinux errors and then I came across this issue.
I don't agree with Harald's language, but I do agree that a breaking change like this shouldn't have been pushed to a stable release. I suspect my systemd selinux problem is that I'm trying to run the session as root and that's not supported, so I will need to move things around now.
(In reply to Samuel Sieb from comment #12) > The command I have been using for years "vncserver -geometry 1024x768 :2" > still doesn't work with that new update. I get a message about it failing > to start Xvnc possibly because of a font server problem, then it dies with: > Fatal server error: > (EE) Unrecognized option: -session > It woks for me. I don't think there is any "-session" parameter passed from vncserver. Are you sure you run "/usr/bin/vncserver"? > I attempted to get the systemd service to work, but I was running into > selinux errors and then I came across this issue. In the HOWTO.md file there is mentioned that for already existing VNC configuration you either need to remove the ~/.vnc/ folder and let it be recreated again running "vncpasswd" to get proper SELinux context or call "restorecon -RFv ~/.vnc/".
Yes, it was definitely /usr/bin/vncserver. restorecon doesn't work on /root/.vnc, only on /home/user/.vnc. Maybe I could have got it to work by manually relabelling it, but I just moved everything to a new user and it's working now.
FEDORA-2020-98137c59f8 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.