Incus项目WebSocket并发写入问题分析与修复

问题背景

在Incus容器管理系统的Web UI中，当用户频繁切换控制台页面时，系统服务进程incusd会出现崩溃现象。这个问题源于WebSocket连接处理中的并发写入竞争条件，导致系统服务不可用。

技术分析

问题现象

用户在使用Incus Web UI时，执行以下操作序列会触发问题：

1. 打开容器/虚拟机的文本控制台
2. 切换到其他标签页(如配置页面)
3. 再次返回控制台页面
4. 重复上述操作数次后，incusd服务崩溃

崩溃日志显示错误信息为"panic: concurrent write to websocket connection"，表明存在并发写入WebSocket连接的问题。

根本原因

通过分析代码，发现问题出在instance_console.go文件的doConsole函数中。该函数处理控制台WebSocket连接时存在以下设计缺陷：

1. 使用ws.Mirror函数在一个单独的goroutine中处理conns[0]的连接
2. 当consoleDoneCh通道关闭时，会触发两个并发的写入操作：
   • 主goroutine中的conns[0].WriteMessage调用
   • ws.Mirror内部goroutine中的关闭操作(最终也会调用WriteMessage)

这两个并发操作没有使用互斥锁进行同步，违反了WebSocket连接的单线程写入原则，导致竞争条件。

代码层面分析

在doConsole函数中，关键问题代码如下：

// 在一个goroutine中启动Mirror
go func() {
    ws.Mirror(conns[0], console)
    close(consoleDoneCh)
}()

// ...

// 当需要关闭时，直接写入消息
conns[0].WriteMessage(websocket.TextMessage, []byte("\r"))

而ws.Mirror内部在关闭连接时也会执行写入操作：

func (w *wrapper) Close() {
    w.conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, ""))
}

这两个写入操作可能同时发生，导致panic。

解决方案

修复方案相对直接：移除主goroutine中的直接写入操作，因为ws.Mirror已经提供了完整的连接管理功能，不需要额外的写入操作。这样可以确保所有WebSocket写入操作都在同一个控制流中完成，避免并发问题。

技术启示

这个案例展示了在Go语言中处理WebSocket连接时需要注意的几个关键点：

1. WebSocket连接不是线程安全的，所有写入操作必须串行化
2. 使用高层抽象(如ws.Mirror)时，应该完全信任其封装的功能，避免混合使用底层操作
3. 通道(Channel)关闭事件的处理需要特别注意可能引发的并发操作
4. 在goroutine间共享资源时，必须明确所有权和控制流

总结

Incus项目中的这个WebSocket并发写入问题是一个典型的多线程资源竞争案例。通过分析，我们发现问题的根源在于对WebSocket连接管理的不当设计。修复方案通过简化控制流，消除了潜在的竞争条件，提高了系统的稳定性。这个案例也提醒开发者在使用goroutine和共享资源时需要格外谨慎，确保资源的访问是线程安全的。