Bug 2060308
| Summary: | automatic start of vncserver service fails after upgrading from RHEL8.6 to RHEL 9.0 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Martin Krajnak <mkrajnak> |
| Component: | tigervnc | Assignee: | Jan Grulich <jgrulich> |
| Status: | CLOSED NOTABUG | QA Contact: | Martin Krajnak <mkrajnak> |
| Severity: | low | Docs Contact: | Marek Suchánek <msuchane> |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | jgrulich, jkoten, pasik, rduda, tpelka, tpopela |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
.VNC is not running after upgrading to RHEL 9
After upgrading from RHEL 8 to RHEL 9, the VNC server fails to start, even if it was previously enabled.
To work around the problem, manually enable the `vncserver` service after the system upgrade:
[subs=+quotes]
----
# systemctl enable --now vncserver@:__port-number__
----
As a result, VNC is now enabled and starts after every system boot as expected.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-07-25 11:45:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hi Jan, I've written a release note to document this known issue. Could you please review the Doc Text field? (In reply to Marek Suchánek from comment #1) > Hi Jan, > I've written a release note to document this known issue. Could you please > review the Doc Text field? Hi, it looks good to me. It is already documented and there is no fix for this migration we can provide. @rduda FYI. |
Description of problem: Despite vncserver being enabled on RHEL8.6, the service fails to start automatically after update to RHEl9.0. The service works once it is again manually enabled on RHEL9.0. Version-Release number of selected component (if applicable): tigervnc-1.11.0-21.el9.x86_64 How reproducible: always Steps to Reproduce: 1.setup tigervnc service on RHEL8.6, then start it -> systemctl enable --now vncserver@:55 2.upgrade to RHEL9.0 Actual results: ○ vncserver@:55.service - Remote desktop service (VNC) Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2022-02-25 08:47:17 EST; 22min ago Main PID: 839 (code=exited, status=0/SUCCESS) CPU: 28ms # journalctl -u vncserver@:55 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Installed new job vncserver@:55.service/start as 287 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: starting held back, waiting for: basic.target Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: starting held back, waiting for: network.target Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: About to execute /usr/libexec/vncsession-restore :55 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Forked /usr/libexec/vncsession-restore as 807 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Changed dead -> start-pre Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: Starting Remote desktop service (VNC)... Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[807]: vncserver@:55.service: Executing: /usr/libexec/vncsession-restore :55 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Child 807 belongs to vncserver@:55.service. Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Control process exited, code=exited, status=0/SUCCESS (success) Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Got final SIGCHLD for state start-pre. Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Passing 0 fds to service Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: About to execute /usr/libexec/vncsession-start :55 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Forked /usr/libexec/vncsession-start as 830 Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Changed start-pre -> start Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Control group is empty. Mar 03 08:42:19 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[830]: vncserver@:55.service: Executing: /usr/libexec/vncsession-start :55 Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Child 830 belongs to vncserver@:55.service. Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Control process exited, code=exited, status=0/SUCCESS (success) Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Got final SIGCHLD for state start. Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: New main PID 837 does not belong to service, but we'll accept it since PID file is owned by root. Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Main PID loaded: 837 Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Changed start -> running Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Job 287 vncserver@:55.service/start finished, result=done Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: Started Remote desktop service (VNC). Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Child 836 belongs to vncserver@:55.service. Mar 03 08:42:20 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Control group is empty. Mar 03 09:42:29 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Changed dead -> running Mar 03 09:42:29 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Control group is empty. Mar 03 09:43:47 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Changed dead -> running Mar 03 09:43:47 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Control group is empty. Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Child 837 belongs to vncserver@:55.service. Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Can't open PID file /run/vncsession-:55.pid (yet?) after running: Operation not permitted Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Main process exited, code=exited, status=0/SUCCESS (success) Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Deactivated successfully. Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Service will not restart (restart setting) Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Changed running -> dead Mar 03 09:45:00 zalman1-vm12-c-01.tpb.lab.eng.brq.redhat.com systemd[1]: vncserver@:55.service: Consumed 17ms CPU time. Expected results: the service should be running. Additional info: Once we execute systemctl enable --now vncserver@:55 on RHEL9.0 everything works as expected, service is automatically started and works after the next reboot. After careful evaluation, we concluded that this cannot be fixed by tigervnc nor systemd, therefore we are creating this bug for documentation purposes so we can make sure that customers will know about the issue.