Dialing to send server error

[AmaruCoder]

When using the lf file manager in Alacritty, I keep receiving the message: dialing to send server: dial unix (a file name ending in sock) followed by connect: no such file or directory (see below).

I have tried lf with iTerm without getting this error.

To make things interesting, after I open lf in iTerm, lf stops giving the error message in Alacritty. Is this a bug or reflects a setting I am not aware of?

System

OS: MacOS Ventura 13.4.1
Alacritty version: 0.12.2
LF version: r31

[joelim-work]

That looks like the socket used for remote commands. Check that the file exists and the server is running. You can also perform a basic test using the following command:

lf -remote 'send echo hello world'

[AmaruCoder]

Thank you. When I run lf -remote 'send echo hello world', I get the same error message (see below). When I navigate to the folder involved, there is no lf.{user}.sock file. However, when I run lf in iTerm, there is no error, and there is a lf.{user}.sock file.

So it seems that lf doesn't start the server under Alacritty. Is it there a way to fix that?

[joelim-work]

There must be something wrong with your settings for Alacritty then, if remote commands work on iTerm.

The socket path is defined in the following code, which depends on XDG_RUNTIME_DIR:

lf/os.go

Lines 123 to 128 in 12e99fd

	runtime := os.Getenv("XDG_RUNTIME_DIR")
	if runtime == "" {
	runtime = os.TempDir()
	}
	gDefaultSocketPath = filepath.Join(runtime, fmt.Sprintf("lf.%s.sock", gUser.Username))

[joelim-work]

Also it might be possible for some reason the server itself doesn't start automatically on Alacritty? In that case you can try starting the server manually using lf -server.

[AmaruCoder]

Thank you for the detailed response. I tried starting the server in Alacritty, using lf - server, but it didn't resolve the issue. I also tried to define XDG_RUNTIME_DIR without better luck. It seems, then, that the problem is that, somehow, the server doesn't get started when lf runs in Alacritty.

Again, if I run lf in iTerm and then in Alacritty, everything works.

[joelim-work]

You have added an extra space, the command is lf -server, not lf - server.

Otherwise I'm not sure what the issue can be then. I tried using Alacritty and couldn't reproduce your issue. The server should either start and print hi! then continue running, or terminate with some error (e.g. socket already in use).

[AmaruCoder]

I posted in the Alacritty Issues page, but they state that it is a problem with lf. Any suggestions to go from here?

[joelim-work]

I didn't think it was an issue with Alacritty to begin with in the first place. However since I don't have any issues with the server starting up using Alacritty, it's practically impossible for me to investigate.

Unless you're willing to clone the repo and debug the following code yourself:

lf/main.go

Lines 335 to 337 in 12e99fd

	if !gSingleMode {
	checkServer()
	}

lf/main.go

Lines 159 to 179 in 12e99fd

	func startServer() {
	cmd := detachedCommand(os.Args[0], "-server")
	if err := cmd.Start(); err != nil {
	log.Printf("starting server: %s", err)
	}
	}
	func checkServer() {
	if gSocketProt == "unix" {
	if _, err := os.Stat(gSocketPath); os.IsNotExist(err) {
	startServer()
	} else if _, err := net.Dial(gSocketProt, gSocketPath); err != nil {
	os.Remove(gSocketPath)
	startServer()
	}
	} else {
	if _, err := net.Dial(gSocketProt, gSocketPath); err != nil {
	startServer()
	}
	}
	}

[joelim-work]

Also if you're not interested in any of this server stuff, you can also try using lf -single instead of lf, which runs just the file manager itself without the server.

[AmaruCoder]

Thank you for the detail reply. lf -single works fine. Of course, multiple windows are not an option for file operations. Regarding the code, unfortunately I haven't learned Go yet. I think that I will stick to iTerm for the time being. Thank you, again.

[AmaruCoder]

I don't know if this helps.

I have tested under MacOs 13.4.1, Terminal, iTerm, and Alacritty, and all of them have the same issue discussed above.

iTerm worked because I had a shortcut to start lf in the form: lf /{bookmarks folder}.

I tried the same shortcut under Terminal and Alacritty, and both also work fine. My {bookmarks folder} is the path to a folder with symlinks to the folders I use most often.

I have made an alias to run lf that way, and that solves the issue. The alias is alias mylf='lf /{bookmarks folder}, where {bookmark folder} points to a folder within my home folder.

Why this works? It's still a mystery to me.

[joelim-work]

So you're saying that running lf by itself doesn't cause the server to start, but running lf /some/path does? Have you tried starting lf directly on the command line without any kind of aliases, shortcuts or any other configuration at all?

Also have you tried enabling logging with the -log option?

I still can't reproduce this issue, but I'm guessing it might have something to do with the value of os.Args[0] in the line cmd := detachedCommand(os.Args[0], "-server"), though I could be completely wrong.

P.S. Another approach might be to use strace to log system calls made by lf. Assuming the server is created properly, it should fork a child process for the server and make an exec call with the appropriate arguments (requires the --follow-forks option to see this).

[AmaruCoder]

I solved the issue. I downloaded Kitty, just to try another terminal, and after trying to run lf, I got the message lf not in $PATH. Which seemed strange, because I had installed lf under my user folder, which is in $PATH.

So I moved lf to /usr/local/bin, which appears earlier on my $PATH, and restarted the terminal. Now lf works everywhere!

Thank you for your help and patience. I really appreciate it. And, by the way, I wanted to troubleshoot this issue because I believe that lf is the best file manager out there.

[joelim-work]

No worries, glad you solved your issue. 👍

It's good that you have the patience to try out different things (e.g. installing another terminal) to figure out the root cause. Others might have given up, assumed it was a bug in lf, and moved onto a different file manager.