Do we still support running extra Sidekiq processes by command line?

Problem to solve

A customer recently tried to start extra Sidekiq processes via the command line as documented here: https://docs.gitlab.com/ee/administration/operations/extra_sidekiq_processes.html#starting-extra-processes-via-command-line

It didn't work out of the box, and I had to create a small wrapper script for the customer to get the command to run (see below, under proposal).

I would like to clarify if this is an option that we want to support, especially since:

1. The recommended way to do this is via /etc/gitlab/gitlab.rb configuration
2. The command line option no longer works out of the box

Error output

# /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster -e production -r /opt/gitlab/embedded/service/gitlab-rails geo,post_receive,cronjob --negate

/usr/bin/env: ruby: No such file or directory

Proposal

If this is no longer supported, we should remove the documentation section.

If it is supported, we can add the below script to Omnibus and then update the documentation to use the new gitlab-sidekiq-cluster command.

Binary environment wrapper

#!/bin/sh

# Unset ENV variables that might interfere with
# omnibus-gitlab ruby env (looking at you rvm, and bundler)
for ruby_env_var in RUBYOPT \
                    RUBYLIB \
                    BUNDLE_BIN_PATH \
                    BUNDLE_GEMFILE \
                    GEM_PATH \
                    GEM_HOME
do
  unset $ruby_env_var
done

error_echo()
{
  echo "$1" 2>& 1
}

gitlab_rails_rc='/opt/gitlab/etc/gitlab-rails/gitlab-rails-rc'
if ! [ -f ${gitlab_rails_rc} ] ; then
  error_echo "$0 error: could not load ${gitlab_rails_rc}"
  error_echo "Either you are not allowed to read the file, or it does not exist yet."
  error_echo "You can generate it with:   sudo gitlab-ctl reconfigure"
  exit 1
fi

. ${gitlab_rails_rc}

cd /opt/gitlab/embedded/service/gitlab-rails

if [ -n "$NO_PRIVILEGE_DROP" ]; then
  privilege_drop=''
elif [ "$(id -n -u)" = "${gitlab_user}" ] ; then
  # We are already running at the intended privilege; don't try to drop
  # privileges again because only root can do that (and we are apparently not
  # root!).
  privilege_drop=''
else
  privilege_drop="-u ${gitlab_user}:${gitlab_group}"
fi

exec /opt/gitlab/embedded/bin/chpst -e /opt/gitlab/etc/gitlab-rails/env ${privilege_drop} -U ${gitlab_user}:${gitlab_group} /opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster "$@"

Who can address the issue

I'm not sure. Need help here!

Other links/references

Zendesk ticket (internal use)