Closed scottwn closed 1 year ago
Looks like scli is starting too many processes in the background, opening a file handle for each. These are dbus-send
commands that scli runs concurrently on startup, to query the signal-cli daemon for the user's groups' names and members.
Are you a member of many groups on this account? (I don't think the number of unread messages in those groups is a factor). I don't know why it works the second time; my guess is it's just luck, and that time the background processes return and close quickly enough to not hit the limit.
It's probably a good idea to limit the number of concurrent processes scli can spawn. In the meantime, you can increase the number of file handles any process can open (with e.g. ulimit -n 2048
, this will only affect the current shell; see https://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files)
Also, scli has not been closing some of the file streams when it should have been. Could you please try the https://github.com/isamert/scli/tree/hotfix/199 branch and see if it fixes this issue?
I'm not a member of too many groups. <10 groups.
I switched to hotfix/199
and since then I have not seen this issue, everything is working well.
I'm seeing this error on tip of master (e65ece04fbab2bbc79dce1724bc5b50d3888f8b3). Should I open another issue?
This is indeed still happening. (Especially after the changes in 8ccae9f08afd28682af69b9512304152a4e3b5af).
Tracking this issue in #205.
When I start scli while there are 100s of unread group messages in my account, startup fails with this error
After the initial failure, I can start scli successfully as normal.