TigerVNC服务器1.15.0版本中xinetd启动问题的分析与解决

TigerVNC作为一款优秀的开源VNC实现，在1.15.0版本中出现了一个影响xinetd启动方式的重要问题。本文将深入分析该问题的成因、影响范围以及解决方案。

问题现象

当用户使用xinetd方式启动TigerVNC 1.15.0服务器时，客户端连接会失败并显示错误信息"Reading version failed: not an RFB server?"。这个问题在1.14.1及更早版本中并不存在，是1.15.0版本引入的回归性问题。

问题根源

经过开发团队分析，问题源于1.15.0版本中的代码变更。在5cd38b6这次提交中，Xvnc服务器开始无条件地发送版本标识横幅(banner)，即使在使用-inetd选项时也是如此。这违反了RFB协议规范，因为当通过xinetd启动时，服务器应该直接进入RFB协议握手阶段，而不应该先发送横幅信息。

技术细节

在VNC协议中，客户端连接时首先期望接收的是版本标识字符串。当服务器错误地先发送了横幅信息后，客户端会将这些横幅文本误认为是版本标识，导致协议解析失败。这个问题特别影响通过xinetd启动的场景，因为xinetd启动的服务通常不应该输出任何额外的信息。

解决方案

开发团队在1f1aaca提交中修复了这个问题。修复方案是让Xvnc服务器模仿Xorg服务器的行为，在检测到-inetd参数时跳过横幅的输出。具体实现是通过检查命令行参数，当存在-inetd选项时，不调用vncPrintBanner()函数。

这个修复确保了：

1. 通过xinetd启动时，服务器直接进入RFB协议握手
2. 保持与之前版本的行为一致性
3. 不影响非xinetd启动方式的使用

影响评估

该问题主要影响：

1. 使用xinetd启动TigerVNC服务器的环境
2. 升级到1.15.0版本的用户
3. 依赖自动化VNC连接的工具和脚本

对于使用systemd或其他启动方式的用户则不受此问题影响。

临时解决方案

对于无法立即升级的用户，可以采用以下临时解决方案之一：

1. 回退到1.14.1版本
2. 应用monnerat提供的补丁，修改xvnc.c文件中的相关逻辑
3. 改用systemd socket激活方式替代xinetd

最佳实践建议

为避免类似问题，建议用户：

1. 在生产环境升级前进行充分测试
2. 关注项目的发布说明和已知问题
3. 考虑使用更现代的systemd替代传统的xinetd
4. 保持VNC客户端和服务器的版本同步

该问题的快速修复体现了TigerVNC开发团队对用户反馈的重视和响应速度，也展示了开源社区协作解决问题的效率。