IOError: [Errno 24] Too many open files: './banlist.dat' about cuwo HOT 11 CLOSED

I can't seem to reproduce this. What fds are open when this happens?

from cuwo.

Can you tell me how to see what FDS are open? I'm on Debian 8. I'm familiar with most things but not familiar with what you're wanting exactly.

from cuwo.

That's my first thought, Cubexed - we have a ton of files on the server but the limit is very high.

from cuwo.

Already implemented SQLite storage actually used for storing user data and bans in my forge that maybe will be merged.

from cuwo.

I think the banlist.dat issue is caused by a machine with too many file descriptors open, and I doubt it's caused by cuwo. The only file descriptors it opens (excluding the ones used by Python) are banlist.dat, the IRC connection and the connections to the client, so I suspect it's something on Kainzo's machine.
Also, we are not going to use SQLite for databases for ban.py. Python dicts will work fine for our purposes.

from cuwo.

The file is closed in any case after fp goes out of scope due to the GC (even though the 'with' statement will close it - there's a reason we use it versus open()). load_data() is not the culprit, and I'm pretty sure it's a fault on Kainzo's machine.

Closing for the time being. Kainzo, feel free to ping me if you still think this is an issue in cuwo after testing on a new user on your box. Thanks.

from cuwo.

Yes, using SQLite database instead solves all these issues without changing system configuration (increasing the amount of file descriptors) and has many more advantages when you e.g. have to find out if player x has been banned with thousands of entries in banlist.dat you can instead use a simple SELECT query.

Increasing the amount of maximum open file descriptors also should help in the case you are handling lots of files that are open at the same time.

from cuwo.

SQLite doesn't fix anything, and it would be an unnecessary dependency for the project. Python's dict implementation is fast, so there's no need for some retarded database library when it only contains a couple of thousand entries.

from cuwo.

The SQLite library is included in pythons default libraries.

from cuwo.

I did not realize that - my bad. But in any case, we should language-native types instead of a database library, as a database library is added complexity that comes with absolutely no gains (no, it does not improve performance if we're talking just a couple of thousand entries). Dictionaries are fine. You could consider writing a script that uses SQLite, but it should not be in the core server.

from cuwo.

Nope. It is more complex when you need to write own database-like functionality than using an existing free, reliable, well known and fast database engine. Using a database engine gives more flexibility.

from cuwo.