SEGFAULT in `gitlab-runner unregister`
Summary
I'm currently setting up a CI/CD pipeline for our project. This pipeline runs various jobs in a set of VMs to build and deploy our code. In order to test things, I manually created and registered a project-level runner for one of our repos in each VM. Once I had everything working, I created a group-level runner in each VM and switched the pipeline over to using those.
Everything worked fine until I tried to unregister the now-redundant project-level runners using gitlab-runner unregister and got a SEGFAULT.
Steps to reproduce
- Registered project-level runner manually with
sudo gitlab-runner register - Registered group-level runner manually with
sudo gitlab-runner register - Attempted to unregister project-level runner manually with
sudo gitlab-runner unregister- SEGFAULT happens if I give no arguments, the name of an existing runner, or the name of a non-existent runner
- Does not happen if I give
--help - No jobs were running in either runner when I tried the unregister command
Actual behavior
SEGFAULT
Expected behavior
Runner is unregistered
Relevant logs and/or screenshots
vagrant@sentinel-dev:~$ sudo gitlab-runner unregister sentinel-dev-cicd-test
Runtime platform arch=amd64 os=linux pid=339970 revision=9882d9c7 version=17.2.1
Running in system-mode.
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1413715]
goroutine 1 [running]:
main.main.func1()
/builds/gitlab-org/gitlab-runner/main.go:52 +0x54
panic({0x2197140?, 0x3d8b4d0?})
/usr/local/go/src/runtime/panic.go:770 +0x132
gitlab.com/gitlab-org/gitlab-runner/commands.(*UnregisterCommand).unregisterSingleRunner(0xc0007fa2d0)
/builds/gitlab-org/gitlab-runner/commands/unregister.go:45 +0xf5
gitlab.com/gitlab-org/gitlab-runner/commands.(*UnregisterCommand).Execute(0xc0007fa2d0, 0x3db4160?)
/builds/gitlab-org/gitlab-runner/commands/unregister.go:82 +0x9e
github.com/urfave/cli.HandleAction({0x2045760?, 0xc0011190b0?}, 0xa?)
/go/pkg/mod/github.com/urfave/cli@v1.22.14/app.go:526 +0x75
github.com/urfave/cli.Command.Run({{0x25982a7, 0xa}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x25c04a8, 0x1a}, {0x0, ...}, ...}, ...)
/go/pkg/mod/github.com/urfave/cli@v1.22.14/command.go:175 +0x685
github.com/urfave/cli.(*App).Run(0xc001374380, {0xc000050210, 0x3, 0x3})
/go/pkg/mod/github.com/urfave/cli@v1.22.14/app.go:277 +0xb3b
main.main()
/builds/gitlab-org/gitlab-runner/main.go:82 +0x6f3
Environment description
My VMs are all Ubuntu 22.04 boxes, running in Virtualbox and configured with Vagrant.
Vagrantfile
Vagrant.configure("2") do |config|
config.vm.box = "generic/ubuntu2204"
config.vm.define 'sentinel-dev'
config.vm.hostname = 'sentinel-dev'
config.ssh.compression = false
config.ssh.keep_alive = true
config.vm.synced_folder "./gitlab-runner/", "/etc/gitlab-runner/"
config.vm.provider "virtualbox" do |vb|
vb.name = 'sentinel-dev'
vb.gui = false
vb.memory = "1024"
vb.cpus = "1"
end
end
config.toml contents
concurrent = 1
check_interval = 10
connection_max_age = "15m0s"
shutdown_timeout = 30
[session_server]
session_timeout = 1800
[[runners]]
name = "sentinel-dev-cicd-test"
url = "https://gitlab.com"
id = 40421589
token = "glrt-[REDACTED]"
token_obtained_at = 2024-08-06T04:48:56Z
token_expires_at = 0001-01-01T00:00:00Z
executor = "shell"
[runners.custom_build_dir]
[runners.cache]
MaxUploadedArchiveSize = 0
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[[runners]]
name = "sentinel-dev"
url = "https://gitlab.com"
id = 40462256
token = "glrt-[REDACTED]"
token_obtained_at = 2024-08-07T21:33:17Z
token_expires_at = 0001-01-01T00:00:00Z
executor = "shell"
[runners.custom_build_dir]
[runners.cache]
MaxUploadedArchiveSize = 0
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
Used GitLab Runner version
Version: 17.2.1
Git revision: 9882d9c7
Git branch: 17-2-stable
GO version: go1.22.5
Built: 2024-07-25T17:34:53+0000
OS/Arch: linux/amd64
Possible fixes
As a workaround, manually deleting the relevant lines for the unwanted runner from config.toml seems to have worked
Related
-
#37909 (closed): Primary complaint is that automatic unregistration inside Kuberenetes pods is broken; ticket also reports the same SEGFAULT when giving no arguments to
unregister, but says it works fine when given valid credentials