Open isti115 opened 9 months ago
That sounds strange to me, lf
has a separate thread for reading from the server: https://github.com/gokcehan/lf/blob/6abce048550a582aff0105012baaf92e940a51da/client.go#L124-L127
So even if that stalls, then in theory it shouldn't interrupt the rest of the application.
I don't have any real ideas of what could cause this, but you might find it helpful to enable logging. Both the server and the client accept a -log
option where you can specify a path for the log file.
I have been experiencing this issue from time to time for quite a while now without being able to pinpoint any exact cause or reproduce it reliably, but decided to post about it anyway. Maybe someone can give me ideas for further investigation, or if nothing else, at least a workaround for restoring operation will be documented for others, who might face this situation and look for help here.
So, I am quite a heavy user of
lf
, I currently have 16 different instances open (across multiple virtual workspaces) according topgrep
. Sometimes when I try to execute an operation (e.g. rename, paste etc.) thelf
instance I'm currently in locks up completely (not even navigation works). After this, the rest of the instances are instantly subject to the same fate as soon as I attempt any operation in any of them (until then the navigation still works).This leads me to believe that they're waiting for a response from the server, that is effectively dead at this point. The way to restore functionality is to kill the server processes, manually delete the sockets (
/run/user/<user_id>/lf.<user_name>.sock
) they left behind and start a new server (lf --server
). This brings the previously frozen clients back to life as well.