-
Notifications
You must be signed in to change notification settings - Fork 982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd vnc service does not startup properly during VM startup when user home is mounted with NFS root squash #1895
Comments
Also as an FYI, the syslog.target referenced in the systemd unit file does not appear to exist on Oracle Linux 9.5: [root@sroth-ol9 ~]# systemctl status syslog.target This does not appear to be the cause of this issue, and does not appear to cause issues during startup, just FYI. |
root squash was actually considered during the design, so it should not be the problem. The fact that a delay resolves is supports that theory. Perhaps the issue is that the service starts before the home directory is mounted? Please restore the service file to original and reboot. Then check the output of the command |
This is the output from systemd-analyze critical-chain vncserver@:2.service:
I also tried changing the service dependencies to explicitly add dependencies on the autofs mount:
Unfortunately, this also did not resolve the issue. In journalctl logs, this is potentially interesting -- in this case I have sroth (autofs home directory with root squash) on :2 and srothlocal (local home directory): on :3. Notice the 'failure creating' permission denied message. This directory /home/sroth/.local/state/tigervnc already exists, and for ~sroth/.local and below, all directories have sroth owner and 777 permissions. So I would expect only root would get this Permission Denied message, because root-squash is enabled. All other users should be able to write to that directory.
|
Even with the mods above, I tried verifying the home directory was available during the ExecStart phase and indeed found it is not. So clearly this is still an issue with my systemd config and my home directory not being available. I'll continue investigating on this side. |
Thanks. Unfortunately, I would expect to see Since this seems to be a general issue, and not a TigerVNC specific one, I'll close this issue for now. Feel free to update us if you find something new that indicates that it is a problem with our service. |
Describe the bug
systemd vnc service does not start properly during VM startup when user home is mounted with NFS root squash.
To Reproduce
Actual behavior for step 10 is:
[sroth@sroth-ol9 ~]$ systemctl status vncserver@:2.service
○ vncserver@:2.service - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/vncserver@:2.service; enabled; preset: disabled)
Active: inactive (dead) since Fri 2025-01-10 11:21:46 EST; 4min 8s ago
Duration: 4ms
Process: 2361 ExecStartPre=/usr/libexec/vncsession-restore :2 (code=exited, status=0/SUCCESS)
Process: 2370 ExecStart=/usr/libexec/vncsession-start :2 (code=exited, status=0/SUCCESS)
Main PID: 2377 (code=exited, status=0/SUCCESS)
CPU: 24ms
Expected behavior
vncserver@:2.service should be Active and port 5902 should be open.
Server (please complete the following information):
Additional context
With a local user, the vncserver service starts up properly during VM startup.
It appears that vncservice (as root) is trying to write to the user's home directory at path ~/.local/state/tigervnc. I see the following logged in journalctl:
[root@sroth-ol9 ~]# journalctl -fe|grep vnc
Jan 10 15:12:51 sroth-ol9.... vncsession[2406]: pam_unix(tigervnc:session): session opened for user sroth(uid=....) by sroth(uid=0)
Jan 10 15:12:51 sroth-ol9.... vncsession[3057]: Failure creating "/home/sroth/.local/state/tigervnc": Permission denied
Jan 10 15:12:51 sroth-ol9..... vncsession[2406]: vncsession: vncserver exited with status=71
It also seems to work properly for a user with a NFS root squash home directory if I change the systemd service file to delay startup until the end of the VM startup process, by changing
After=syslog.target network.target systemd-user-sessions.service
to
After=multi-user.target
I'm not sure why/how that changes the behavior, but it provided a workaround in my case.
The text was updated successfully, but these errors were encountered: