serverstop hangs on TeamSpeak Server 6.0.0-beta13 when a file transfer is pending on the virtual server: the stop never finishes, the virtual server stays in shutting down, and only restarting the whole server process brings it back. Worse, the state is permanent. After that, every serverstop on that virtual server hangs the same way, on a freshly started process, with nothing pending. In every other respect the virtual server keeps working normally.
Version / environment
- TeamSpeak Server 6.0.0-beta13 (2026-09-17 11:38:23), build 1789645103
SystemInformation: Linux 6.18.33.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC x86_64 Binary: 64bit- Official
teamspeaksystems/teamspeak6-servercontainer, Docker on that host - Database:
MariaDB plugin, version 3, dbPlugin version 2 - No licence:
max virtualservers: 1,max slots: 32; one virtual server, sid 1 - SSH ServerQuery on 10022, HTTP WebQuery on 10080, file transfer on 30033
Steps to reproduce
- Announce an upload and never start it, which is the state a client leaves behind when it loses its connection mid-upload:
use sid=1
ftinitupload clientftfid=1 name=/stop-experiment.bin cid=<any channel> cpw= size=1048576 overwrite=1 resume=0
Do not connect to the file transfer port.
- Check that the server holds it as waiting:
ftlist
→ clientftfid=1 serverftfid=1 ... status=0
- Stop the virtual server:
serverstop sid=1
Expected
The stop completes. The pending transfer is one the server abandons by itself after about two minutes, so at worst the shutdown should take that long. A refusal with a status code would be fine too.
Actual
serverstopnever answers. My client gave up after 30 seconds.serverlistreportsvirtualserver_status=shutting downand stays there. In the run logged below it was still doing so after more than fifteen minutes, when I stopped watching, and never less than six minutes in the other runs. That is far past the point where the pending transfer has lapsed.- The instance log repeats every ten seconds, from the moment of the stop:
ERROR | VirtualSvrMgr | stopserver for sid: 1 still waiting for shutdown use sid=1returns1035 server got an invalid status for this operationandftlistreturns1024, so the pending transfer can no longer be cleared through the query interface.serverstart sid=1returns2816 virtualserver limit reached, because the stuck virtual server still counts against the licence, whilehostinforeportsvirtualservers_running_total=0.- The instance itself stays healthy: SSH, WebQuery,
hostinfoandlogview instance=1all answer. serverprocessstopplus starting the process again is the only way back.
In two earlier occurrences serverstop answered error id=0 msg=ok and the virtual server still never finished shutting down, so whether the command answers appears to depend on timing. The outcome is the same.
Narrowing down
| # | State of the virtual server when the stop was issued | Transfer pending | Result |
|---|---|---|---|
| 1 | Fresh process, never hung before | none | stop and start completed in under a second |
| 2 | Same, with an active servernotifyregister session |
none | the same |
| 3 | After a test run that had moved files a minute earlier | yes, left over | hung |
| 4 | Fresh process, one ftinitupload ticket nobody connected to |
yes, deliberate | hung |
| 5 | Fresh process, stop was the first command after startup | none | hung |
| 6 | Fresh process, the tickets’ 0-byte leftovers deleted, ftgetfilelist and ftlist both 1281 |
none | hung |
| 7 | Fresh process, serversnapshotdeploy run right before, which restarts the virtual server internally and worked fine |
none | hung |
Rows 1 and 2 are from before the virtual server first hung. Every row after it hung once behaves the same, regardless of what is pending. So a pending transfer is how a virtual server gets into this state, and not what it is still waiting for.
Log of run 7 (UTC)
This is the most telling one, because both shutdown paths appear within the same minute, on the same virtual server. The server process starts, serversnapshotdeploy takes the virtual server down and brings it back, logging stopped and startServer(), and the serverstop sent fourteen seconds later never finishes:
11:26:17.219560|INFO |Transport | |listening on 0.0.0.0:9987, [::]:9987
11:26:17.220541|INFO |Query | |listening for ssh query on 0.0.0.0:10022, [::]:10022
11:26:17.403028|INFO | | |myTeamSpeak identifier revocation list was downloaded successfully
<-- serversnapshotdeploy of a snapshot of this same server, answered ok in under a second
11:26:41.812686|INFO |VirtualServer |1 |stopped
11:26:41.988696|INFO |Transport | |listening on 0.0.0.0:9987, [::]:9987
11:26:41.988807|INFO |VirtualSvrMgr | |startServer() VirtualServer(1) started
<-- serverstop sid=1, never answered
11:26:55.594244|ERROR |VirtualSvrMgr | |stopserver for sid: 1 still waiting for shutdown
11:27:05.593719|ERROR |VirtualSvrMgr | |stopserver for sid: 1 still waiting for shutdown
11:27:15.593927|ERROR |VirtualSvrMgr | |stopserver for sid: 1 still waiting for shutdown
... unchanged every ten seconds; still going at 11:42:05, when I stopped watching
The deploy’s shutdown of the very same virtual server completes and logs VirtualServer 1 stopped. The stopserver path, fourteen seconds later, waits forever. Whatever the two paths wait for differs, and that looks like the place to start.
Impact
This is not limited to ServerQuery experimentation. An administrator who stops a virtual server while someone is uploading a file, or has just lost their connection mid-upload, loses the ability to stop that virtual server at all, permanently. Every attempt afterwards costs a restart of the whole server process, which on a multi-server instance takes every other virtual server down with it.
I have found no way back through the query interface. Wiping the server’s database presumably helps, as it did for the snapshot crash I reported in September (-keepfiles crashes the server and leaves the virtual server unrecoverable, fixed in beta13), but that is not something anyone can do to a production server.
Questions
- Is there a way to clear this state without losing the virtual server?
- Do earlier versions behave the same? I only measured 6.0.0-beta13; on 6.0.0-beta12.1 I never issued a stop with a transfer pending.
Note: This analysis was put together with the help of an AI assistant (Claude). It ran the query commands against my test server while developing a ServerQuery tool, and collected the results in one place. The server logs are copied from my own Docker output. The server is a throwaway instance, which is why the runs in the table were allowed to break it on purpose, one condition at a time, over two days. Everything above was measured there; the two questions are the parts I could not answer myself.