Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 08 Jun 2022 21:51:48 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 264558] www/gitlab sidekiq crashes shortly after starting
Message-ID:  <bug-264558-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264558

            Bug ID: 264558
           Summary: www/gitlab sidekiq crashes shortly after starting
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs@FreeBSD.org
          Reporter: gwright@antiope.com

On FreeBSD 13.1-amd64, the sidekiq job dispatcher (a dependency of gitlab-c=
e)
crashes shortly after starting.  This happens with either gitlab-ce version
15.0.0 or version 15.0.1.

An initial restart seems to show everything is running, but after less than=
 a
minute, sidekiq is dead:
```
root@gitlab:/usr/local/www/gitlab-ce/log # service gitlab restart
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break
this application for all non-root users on this machine.
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
installing your bundle as root will break
this application for all non-root users on this machine.
Removing stale Sidekiq job dispatcher pid. This is most likely caused by
Sidekiq crashing the last time it ran.
Shutting down GitLab web server
61650
Shutting down GitLab Workhorse
Shutting down Gitaly
...........
GitLab is not running.
Starting GitLab web server (puma)
Starting GitLab Sidekiq
Starting GitLab Workhorse
Starting Gitaly
.No pidfile found at /usr/local/www/gitlab-ce/tmp/pids/sidekiq-cluster.pid;=
 is
Sidekiq running?
.{"timestamp":"2022-06-08T21:26:41.366Z","pid":35695,"message":"Puma starti=
ng
in cluster mode..."}
{"timestamp":"2022-06-08T21:26:41.366Z","pid":35695,"message":"* Puma versi=
on:
5.6.4 (ruby 3.0.4-p208) (\"Birdie's Version\")"}
{"timestamp":"2022-06-08T21:26:41.366Z","pid":35695,"message":"*  Min threa=
ds:
1"}
{"timestamp":"2022-06-08T21:26:41.366Z","pid":35695,"message":"*  Max threa=
ds:
16"}
{"timestamp":"2022-06-08T21:26:41.367Z","pid":35695,"message":"*  Environme=
nt:
production"}
{"timestamp":"2022-06-08T21:26:41.367Z","pid":35695,"message":"*   Master P=
ID:
35695"}
{"timestamp":"2022-06-08T21:26:41.367Z","pid":35695,"message":"*      Worke=
rs:
8"}
{"timestamp":"2022-06-08T21:26:41.367Z","pid":35695,"message":"*     Restar=
ts:
(=E2=9C=94) hot (=E2=9C=96) phased"}
{"timestamp":"2022-06-08T21:26:41.367Z","pid":35695,"message":"* Preloading
application"}
..Top level ::CompositeIO is deprecated, require 'multipart/post' and use
`Multipart::Post::CompositeReadIO` instead!
Top level ::Parts is deprecated, require 'multipart/post' and use
`Multipart::Post::Parts` instead!
............................................{"timestamp":"2022-06-08T21:27:=
28.689Z","pid":35695,"message":"*
Listening on unix:///usr/local/www/gitlab-ce/tmp/sockets/g
itlab.socket"}
{"timestamp":"2022-06-08T21:27:28.689Z","pid":35695,"message":"! WARNING:
Detected 1 Thread(s) started in app boot:"}
{"timestamp":"2022-06-08T21:27:28.689Z","pid":35695,"message":"!
#\u003cThread:0x0000000834a57828
/usr/local/lib/ruby/gems/3.0/gems/rack-timeout-0.5.2/lib/rack/timeout/
support/scheduler.rb:73 sleep\u003e -
/usr/local/lib/ruby/gems/3.0/gems/rack-timeout-0.5.2/lib/rack/timeout/suppo=
rt/scheduler.rb:91:in
`sleep'"}
{"timestamp":"2022-06-08T21:27:28.689Z","pid":35695,"message":"Use Ctrl-C to
stop"}

Started in 48s.
The GitLab web server with pid 35695 is running.
The GitLab Sidekiq job dispatcher with pid 35705 is running.
The GitLab Workhorse with pid 35711 is running.
Gitaly with pid 35710 is running.
GitLab and all its components are up and running.
root@gitlab:/usr/local/www/gitlab-ce/log # ls -l sidekiq.log
-rw-r--r--  1 git  www  826738 Jun  8 21:27 sidekiq.log
root@gitlab:/usr/local/www/gitlab-ce/log # service gitlab status
The GitLab web server with pid 35695 is running.
The GitLab Sidekiq job dispatcher is not running.
The GitLab Workhorse with pid 35711 is running.
Gitaly with pid 35710 is running.
root@gitlab:/usr/local/www/gitlab-ce/log #
```

The only error I see in /usr/local/www/gitlab-ce/log/sidekiq.log is
```
{"severity":"ERROR","time":"2022-06-05T22:24:21.142Z","message":"Heartbeat
thread error: Error connecting to Redis
 on /var/run/redis/redis.sock (Errno::ENOENT)"}
```
but the redis socket does exist, and the redis process in running:
```
root@gitlab:/usr/local/www/gitlab-ce/log # ps ax | grep redis
60532  -  SsJ  0:11.17 redis-server: /usr/local/bin/redis-server
unixsocket:/var/run/redis/redis.sock (redis-server)
```
I set the log level for redis to `debug` but I see no errors in the log.  Is
there a way to set the sidekiq log level similarly?  I didn't see one, but I
might have missed something.

I tried both a complete uninstall and reinstall of gitlab-ce 15.0.1 from
packages, and sidekiq still crashed a few seconds after starting.  I also d=
id a
complete uninstall and reinstall from ports with the same results.

Without sidekiq, it is not possible to run continuous integration jobs, sin=
ce
they are dispatched by sidekiq.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264558-7788>