With latest trunk on centos I'm getting a lot of 'error Write-error: locked' entrys in the error.log. I've no idea why and what is locked...

Debug logs would help with diagnosing this. It's most likely a client session being locked, as the string "Write-error" only appears in core.sessionmanager. If you had included the entire log line, this should have been obvious. As for why, from trying to see why locks are used at all, seems either the session is destroyed or somehow got stuck during TLS negotiation.

I think this has something to do with conflict_resolve = increment. This is from the debug log: Oct 27 13:02:21 c2s2fb2e00 info Client disconnected: closed Oct 27 13:02:21 c2s2fb2e00 debug Destroying session for user@domain.de/mobile (user@domain.de): closed Oct 27 13:02:21 c2s2fb2e00 debug mod_smacks hibernating session for up to 1800 seconds Oct 27 13:03:09 c2s2fb2e00 debug Disconnecting client, <stream:error> is: <stream:error><conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Replaced by new connection</text></stream:error> Oct 27 13:03:09 c2s2fb2e00 error Write-error: locked

I've just changed conflict_resolve from increment to kick_old, what is the default value, but error persists. Do you need more logs?

I've information about that issue. I've just registered, that prosody created a journal file and doesn't write any messages to the sqlite database. The Journal file isn't deleted until a restart. My logs are full of write errors. Do you have any ideas? Running prosodyctl check shows: Checking config... Done. lua: /lib/prosody/util/set.lua:50: bad argument #1 to \' ipairs\' (table expected, got number) stack traceback: [C]: in function \'ipairs\' /lib/prosody/util/set.lua:50: in function \'add_ list\' /lib/prosody/util/set.lua:73: in function \'new\' /bin/prosodyctl:960: in function \'?\' /bin/prosodyctl:1299: in main chunk [C]: ? What is wrong? The errors began with prosody trunk build 587 or with modules published around that build.

That sounds like it belongs to #464

hmm, I don't think so, my prosody data folder, where the sqlite database and other prosody data is stored is read- and writeable. Are there any limits for line-sizes or file-sizes for prosody.sqlite database file?

This seems to be the relevat change in source code, which causes the never ending log entries: http://hg.prosody.im/trunk/rev/eed846384178

I've also noticed, that a regular log out doesn't close the session, smacks is hibernating the sessions although the user goes offline, that should not happen: Oct 31 11:00:53 c2s2662af0 debug Received[c2s]: <presence type='unavailable' from='user@domain.de/mobile'> Oct 31 11:00:53 c2s2662af0 info Client disconnected: closed Oct 31 11:00:53 c2s2662af0 debug Destroying session for user@domain.de/mobile (user@domain.de): closed Oct 31 11:00:53 c2s2662af0 debug mod_smacks hibernating session for up to 1800 seconds The user is still marked as online in my other clients.

Regardless, <q>Write-error: locked</q> does not seem to be related to storage, it's a <b>connection</b> that is locked, not a database. Also, if you get <q>Replaced by new connection</q> then 'conflict_resolve' must be set to 'kick_old' already.

I've already set conflict_resolve to kick-off, but still getting lots of write errors. What is with mod_smacks? Why does it hibernate the sessions although the user logs off?

That happens if the client does not close the stream cleanly.

The developer of Conversations have commited a fix for closing the stream correctly and mod_smacks is not hibernating the session anymore after logging off. But these write-errors are still persistent in the prosody logs. So they were not caused by a dirty closed session/stream. https://github.com/siacs/Conversations/issues/1535 Any ideas?

This seems to be caused by a hack in mod_smacks, in where it transforms stanzas sent to hibernating sessions into the empty string. net.server_select simply ignores this, while net.server_event returns an error, which http://hg.prosody.im/trunk/rev/eed846384178 adds reporting of. Before it would simply have been ignored.

• tag Status-Accepted

This "error" has been demoted to a debug message FWIW.

• owner Zash

I'll close this, since it was mainly an overly loud debug message.

• tags Status-Fixed