ERRO[0000] remove /Users/user/.lima/instance/ssh.sock: no such file or directory

[nirs]

Description

Trying to remove a non-existing file is not an error, but it logged as an error.

% limactl delete -f c1
INFO[0000] Sending SIGKILL to the vz driver process 39645 
INFO[0000] Sending SIGKILL to the host agent process 39645 
INFO[0000] Removing /Users/nsoffer/.lima/c1 under "*.pid *.sock *.tmp" 
INFO[0000] Removing "/Users/nsoffer/.lima/c1/default_ep.sock" 
INFO[0000] Removing "/Users/nsoffer/.lima/c1/default_fd.sock" 
INFO[0000] Removing "/Users/nsoffer/.lima/c1/ha.pid"    
INFO[0000] Removing "/Users/nsoffer/.lima/c1/ha.sock"   
INFO[0000] Removing "/Users/nsoffer/.lima/c1/ssh.sock"  
ERRO[0000] remove /Users/nsoffer/.lima/c1/ssh.sock: no such file or directory 
INFO[0000] Removing "/Users/nsoffer/.lima/c1/vz.pid"    
INFO[0000] Deleted "c1" ("/Users/nsoffer/.lima/c1")     

Deleting a non-existing file may be a real error in the program, maybe left over code trying to remove a file that is never created. But this error is not something that user of the tool should care about. The right way to log such event is a debug message - this allows developers to verify that the system behaves correctly without harming the user experience.

Since the lima log is the user interface, it should never show these kind of issues.

Fix:

• check if the attempt to delete the file is correct
• change to debug message

[jandubois]

trying to remove a file that is never created

The file does exist because it is the result of os.ReadDir:

lima/pkg/instance/stop.go

Lines 95 to 97 in 15c0f6e

	suffixesToBeRemoved := []string{".pid", ".sock", ".tmp"}
	logrus.Infof("Removing %s under %q", inst.Dir, strings.ReplaceAll(strings.Join(suffixesToBeRemoved, " "), ".", "*."))
	fi, err := os.ReadDir(inst.Dir)

So this is a race condition, where the file also gets deleted when the ssh controlpath is closed.

I don't know if this is going to work, but I would try to only report the error if errors.Is(err, os.ErrNotExist) is false. Because if the file got deleted by any other means, then it is not an error.

If you can reliably reproduce this condition, can you add the additional check and see if that fixes it?

[nirs]

This always happen when using delete -f. I'll send a fix later.