Sidekiq service file for systemd (CentOS, Fedora) #43

wants to merge 9 commits into


None yet

5 participants


CentOS and Fedora uses systemd not usual init.d so it needs bit different configuration.

I added sidekiq.service file

first I tried:

ExecStart=/bin/sh -c "cd /home/gitlab/gitlab/ && bundle exec rake sidekiq:start"

but sidekiq was crashing (don't know why, it was launched as gitlab user)

this works fine
ExecStart=/bin/su - gitlab -c "cd /home/gitlab/gitlab/ && bundle exec rake sidekiq:start"

randx commented Jan 21, 2013

Please add header to each file

# Maintainer: @davispuh
# App Version: 4.1


done ;)

there's only one service file: sidekiq.service and I don't see reason why add to README

Also there's just sidekiq because all other services can be installed with package management which creates startup files automatically and there's multiple choices which software to use (eg. nginx or apache)

Also seems I've lied a bit, current stable CentOS release doesn't come with systemd, but it can be installed.

Distributions with systemd as default:

  • Fedora
  • openSUSE
  • Arch Linux
  • Mandriva
  • Mageia
  • Frugalware

Distributions where systemd can be enabled/installed easily:

  • Debian GNU/Linux
  • Gentoo
  • Ubuntu

Why not something more along the lines of:

ExecStart=/home/gitlab/bin/bundle exec rake sidekiq:start RAILS_ENV=production
ExecStop=/home/gitlab/bin/bundle exec rake sidekiq:stop RAILS_ENV=production

The ExecStart/Stop need an absolute path, but this is a lot simpler...

I'll check why it is crashing, if it does, on my Arch machine.


wasn't aware there's WorkingDirectory. I don't see it mentioned anywhere in man pages... using systemd 44 version.
I was looking for something like that but didn't found so had to use shell..

oh, just found man systemd.exec didn't view that... :D


I updated sidekiq service, thanks :)

seems to work good :)

ExecStart=/bin/bundle exec rake sidekiq:start RAILS_ENV=production
ExecStop=/bin/bundle exec rake sidekiq:stop RAILS_ENV=production

whoops... sidekiq is crashing same as my first attempt...

this is from log..

/home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/lib/sidekiq/cli.rb:106:in `block in interrupt': Interrupt (Interrupt)
        from <internal:prelude>:10:in `synchronize'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/lib/sidekiq/cli.rb:103:in `interrupt'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/lib/sidekiq/cli.rb:9:in `block in <top (required)>'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:251:in `call'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:251:in `block in require'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:236:in `load_dependency'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/dependencies.rb:251:in `require'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.11/lib/action_view/template/resolver.rb:4:in `<top (required)>'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.11/lib/action_view/railtie.rb:50:in `block (2 levels) in <class:Railtie>'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:36:in `instance_eval'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:36:in `execute_hook'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:26:in `block in on_load'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:25:in `each'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/lazy_load_hooks.rb:25:in `on_load'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.11/lib/action_view/railtie.rb:48:in `block in <class:Railtie>'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/initializable.rb:30:in `instance_exec'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/initializable.rb:30:in `run'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/initializable.rb:55:in `block in run_initializers'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/initializable.rb:54:in `each'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/initializable.rb:54:in `run_initializers'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/application.rb:136:in `initialize!'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/railtie/configurable.rb:30:in `method_missing'
        from /home/gitlab/gitlab/config/environment.rb:5:in `<top (required)>'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/lib/sidekiq/cli.rb:133:in `require'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/lib/sidekiq/cli.rb:133:in `boot_system'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/lib/sidekiq/cli.rb:74:in `parse'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/sidekiq-2.6.4/bin/sidekiq:7:in `<top (required)>'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/sidekiq:19:in `load'
        from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/sidekiq:19:in `<main>'

I reverted back... I've no idea why sidekiq is crashing... anyway while this config might not be the nicest it does work so unless someone have better one which doesn't crash sidekiq I'm leaving this one.

@nathansamson nathansamson referenced this pull request in gitlabhq/gitlabhq Jan 28, 2013

Alternate solutions for GitLab startup script #2744


So after going crazy trying to get a working sidekiq.service on my arch machine I ended up with this service, where setting Environment=PATH= seems to be the winner for me since sidekiq kept throwing failed to run command on bundle even with absolute paths etc. Kinda assumed there's another bundle call inside which wont find the bundle without the PATH set.

Description=GitLab Sidekiq Service
After=redis.service gitlab.service


ExecStart=/bin/bash -c 'bundle exec rake sidekiq:start RAILS_ENV=production'
ExecStop=/bin/bash -c 'bundle exec rake sidekiq:stop RAILS_ENV=production'


Well idk figured I'd just post it just in case it might actually help someone ^^


this ^ above, doesn't work for me on Fedora, still crash but bit different than earlier.
My previous attempts, it just exits without any sign (no idea why). So currently I don't see any way to run sidekiq with systemd.. It needs to be started manually. If anyone have time, would be great if could look into it.
this is my best try, no luck, but doesn't crash. just exits.

Description=GitLab Sidekiq Service redis.service

ExecStart=/bin/su - gitlab -c "(cd /home/gitlab/gitlab/ && bundle exec rake sidekiq:start RAILS_ENV=production) || 0"
ExecStop=/bin/su - gitlab -c "(cd /home/gitlab/gitlab/ && bundle exec rake sidekiq:stop RAILS_ENV=production) || 0"


|| 0 because otherwise that command returns 1 to systemd and it assumes it failed, even if it's still running.

@axilleas axilleas referenced this pull request Aug 2, 2013

[WIP] New repository structure #111

12 of 14 tasks complete
@axilleas axilleas was assigned Aug 5, 2013

I provided some service files based on many suggestions that play with Fedora (see above commit). Haven't tested with Arch yet. I also included your readme and I added 1-2 things. Feedback welcomed :)

@axilleas axilleas closed this Aug 19, 2013

just tested, works good for my Fedora 18 :) Thanks 👍


Cool! Thanks for the feedback. I'll add your name to the contributors if you don't mind.


sure lol.

When I first tried sidekiq as systemd unit file for some configurations it was crashing, that was when I had F17, maybe some buggy lib/gem somewhere idk, but anyway this unit file is very clean and nice, not sure if you saw any crashes, but I didn't now with this and fully updated system.


No crashes for me too, I tested before pushing on Fedora 19. Will have to do the same for Archlinux.

To give proper credits, I took the sidekiq one from here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment