It's a general assumption that a 0s timer will execute on the next tick. Adding a timer that returns a 0s timeout causes prosody to be non-responsive until the timer returns a longer timeout or stops.

Fixed in https://hg.prosody.im/trunk/rev/1274deeab39a Similar issue in net.server_epoll fixed in https://hg.prosody.im/trunk/rev/2c559953ad41

• tags Status-Fixed
• owner Zash

The fix in prosody 0.11 nightly build 1nightly120-1~buster is broken and spits out endless backtraces while the server is unresponsive: Jan 10 11:52:13 general error Top-level error, please report: /usr/lib/prosody/net/server_epoll.lua:103: attempt to compare number with function Jan 10 11:52:13 general error stack traceback: /usr/lib/prosody/net/server_epoll.lua:103: in function 'runtimers' /usr/lib/prosody/net/server_epoll.lua:754: in function </usr/lib/prosody/net/server_epoll.lua:752> [C]: in function 'xpcall' /usr/bin/prosody:76: in function 'loop' /usr/bin/prosody:86: in main chunk [C]: in ? J