Skip to content

golangci-lint v1.24.0 still appears to not be cleaning up lock file #1021

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
SteelPhase opened this issue Apr 15, 2020 · 5 comments
Closed
Labels
bug Something isn't working

Comments

@SteelPhase
Copy link

SteelPhase commented Apr 15, 2020

Lock file should be cleaned up when running golangci-lint --version or golangci-lint --help

Version of golangci-lint v1.24.0
$ golangci-lint --version
golangci-lint has version 1.24.0 built from 6fd4383 on 2020-03-15T11:38:02Z
Go environment
$ go version && go env
go version go1.14.1 linux/amd64
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/steelphase/.cache/go-build"
GOENV="/home/steelphase/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOOS="linux"
GOPATH="/home/steelphase/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build950404935=/tmp/go-build -gno-record-gcc-switches"
Verbose output of running
$ ls -la /tmp/golangci-lint.lock
ls: cannot access /tmp/golangci-lint.lock: No such file or directory
$ golangci-lint -v --version
INFO [config_reader] Config search paths: [./ /home/steelphase /home /] 
golangci-lint has version 1.24.0 built from 6fd4383 on 2020-03-15T11:38:02Z
$ ls -la /tmp/golangci-lint.lock
-rw-------. 1 steelphase users 0 Apr 15 15:46 /tmp/golangci-lint.lock
@ernado ernado added the bug Something isn't working label Apr 20, 2020
@jirfag
Copy link
Contributor

jirfag commented May 5, 2020

Hi,
thank you,
can't reproduce. Please, re-run golangci-lint with environment variable GL_DEBUG=exec

@SteelPhase
Copy link
Author

SteelPhase commented May 5, 2020

Just tested on linux, and got the below output. looks like golangci-lint version is fine, but gloangci-lint --version is not

$ golangci-lint version
golangci-lint has version 1.26.0 built from 6bd10d0 on 2020-05-01T15:33:57Z
$ export GL_DEBUG=exec
$ ls -la /tmp/golangci-lint.lock
ls: cannot access /tmp/golangci-lint.lock: No such file or directory
$ golangci-lint -v --version
DEBU [exec] Starting execution...                 
DEBU [exec] Locking on file /tmp/golangci-lint.lock... 
INFO [config_reader] Config search paths: [./ /home/steelphase /home /] 
DEBU [exec] Initialized executor                  
golangci-lint has version 1.26.0 built from 6bd10d0 on 2020-05-01T15:33:57Z
$ ls -la /tmp/golangci-lint.lock
-rw-------. 1 steelphase users 0 May  5 14:55 /tmp/golangci-lint.lock
$ golangci-lint -v version
DEBU [exec] Starting execution...                 
DEBU [exec] Locking on file /tmp/golangci-lint.lock... 
INFO [config_reader] Config search paths: [./ /home/steelphase /home /] 
DEBU [exec] Initialized executor                  
golangci-lint has version 1.26.0 built from 6bd10d0 on 2020-05-01T15:33:57Z
$ ls -la /tmp/golangci-lint.lock
ls: cannot access /tmp/golangci-lint.lock: No such file or directory

NOTE: I had to go get because the binary in golangci-lint-1.26.0-freebsd-386.tar.gz refused to work on my machine

On mac:

$GO111MODULE=on go get github.com/golangci/golangci-lint/cmd/[email protected]
go: found github.com/golangci/golangci-lint/cmd/golangci-lint in github.com/golangci/golangci-lint v1.26.0
$export GL_DEBUG=exec
$ls -la  /var/folders/0b/00/T/golangci-lint.lock
ls: /var/folders/0b/00/T/golangci-lint.lock: No such file or directory
$golangci-lint -v --version
DEBU [exec] Starting execution...                 
DEBU [exec] Locking on file /var/folders/0b/00/T/golangci-lint.lock... 
INFO [config_reader] Config search paths: [./ /Users/steelphase /Users /] 
DEBU [exec] Initialized executor                  
golangci-lint has version v1.26.0 built from (unknown, mod sum: "h1:CLLGRSA9BLMiNvsWPXHioYAdfIx9tkgdVWyA6bIdYCo=") on (unknown)
$ls -la  /var/folders/0b/00/T/golangci-lint.lock
-rw-------  1 steelphase  group  0 May  5 15:03 /var/folders/0b/00/T/golangci-lint.lock
$golangci-lint -v version
DEBU [exec] Starting execution...                 
DEBU [exec] Locking on file /var/folders/0b/00/T/golangci-lint.lock... 
INFO [config_reader] Config search paths: [./ /Users/steelphase /Users /] 
DEBU [exec] Initialized executor                  
golangci-lint has version v1.26.0 built from (unknown, mod sum: "h1:CLLGRSA9BLMiNvsWPXHioYAdfIx9tkgdVWyA6bIdYCo=") on (unknown)
$ls -la  /var/folders/0b/00/T/golangci-lint.lock
ls: /var/folders/0b/00/T/golangci-lint.lock: No such file or directory

@SteelPhase
Copy link
Author

SteelPhase commented May 5, 2020

I would say this is the issue for --version os.Exit(0) never lets you close your file lock

As another note version, and --version have two different execution paths. That os.Exit(0) stops --version from closing the lock. help, and --help also have two separate paths and have a similar issue.

if e.cfg.Run.PrintVersion {
fmt.Fprintf(logutils.StdOut, "golangci-lint has version %s built from %s on %s\n", e.version, e.commit, e.date)
os.Exit(0)
}

@ksoichiro
Copy link
Contributor

I confirmed that it can be reproduced on v1.26.0, but not on v1.27.0.
It seems it's already fixed by #1070, which is included in the latest released version: v1.27.0.
So maybe you can resolve this by updating to v1.27.0.

As @SteelPhase pointed out, there were some paths that exits without removing lock file. Removing lock file is executed by cobra.Command's PostRun hook, but it is not set for those cases.
After #1070, it seems those paths don't exist because it is changed to acquiring file lock on PreRun and releasing it on PostRun.

@SVilgelm
Copy link
Member

closing due to the issue is fixed in the v1.27.0 release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants