Re: migrating to Debian gitlab
On 2016, ഫെബ്രുവരി 15 10:05:08 PM IST, Christian Seiler <christian@iwakd.de> wrote:
>On 02/15/2016 04:56 PM, Pirate Praveen wrote:
>> I have to verify if pid file ownership is causing problems. If
>> systemd created pidfile as root and unicorn is writing to it as
>> gitlab user, it will fail. I'll check this now.
>
>systemd does not create any pid files. It only reads them to
>figure out which PID of a multi-process Type=forking service is
>the main PID of that service.
Thanks for the clarification.
>>> - the other services that use ExecStart=/bin/sh bin/$NAME start
>>> and ExecStop=/bin/sh bin/$NAME stop are problematic, because
>>> in the systemd service file you declare PIDFile to be in
>>> /run/gitlab, while the configuration that's read by the gitlab
>>> scripts assumes the path is in /usr/share/gitlab/tmp/pids
>>
>> I have patched those files to read /etc/default/gitlab.
>
>But the PID file names don't match:
>
>/etc/gitlab-debian.conf: gitlab_pid_path=/run/gitlib
>/etc/default/gitlab:
> export $(cat /etc/gitlab/gitlab-debian.conf|xargs)
> pid_path="${gitlab_pid_path}"
> sidekiq_pid_path="$pid_path/sidekiq.pid"
>
>So in the end we have:
>( . /etc/default/gitlab ; echo ${sidekiq_pid_path} ; )
> => gives us: /run/gitlab/sidekiq.pid
>
>grep PIDFile /lib/systemd/system/gitlab-sidekiq.service
> => gives us: PIDFile=/run/gitlab/gitlab-sidekiq.pid
>
>/run/gitlab/sidekiq.pid != /run/gitlab/gitlab-sidekiq.pid
>
>
Thanks a lot, been struggling the whole day to figure this out. The variable names are a mess currently. I hope to clean it up after I fix all rc bugs.
>
>That all said, your main problem is a different one: if you read
>"man systemd.exec", you will find that RuntimeDirectory= is
>removed once a unit exits. So you cannot actually reuse it for a
>set of units, because then it will just be removed once the first
>unit stops. And gitlab-mailroom.service is Type=oneshot, so once
>that's done executing, systemd will remove /run/gitlab - and this
>will then cause a cascade of failures for other units.
>
>The same man page also specifies that more complicated setups
>should use systemd-tmpfiles. So what you should to instead is
>ship a file /usr/lib/tmpfiles.d/gitlab.conf with the following
>contents (the 'd' at the beginning is not (!) a typo, see the man
>pages for tmpfiles.d):
>
>d /run/gitlab 2750 gitlab gitlab -
>
>Then remove all RuntimeDirectory= settings from all service files.
>
>This tmpfiles.d snippet will cause systemd to create the directory
>/run/gitlab on boot with the proper permissions.
>
>dh_installinit now takes care to create code in the #DEBHELPER#
>section of postinst to make sure it's executed.
>
>The easiest way to add that file is to simply create a file
>debian/gitlab.tmpfiles with the contents I mentioned, current
>dh_installinit versions will properly install that file to the
>location in /usr/lib/tmpfiles.d/gitlab.conf.
Thanks again.
>>> Note that PIDFile= with Type=forking is an informational thing for
>>> systemd: it tells systemd where it can find the file containing
>>> the main PID of the service after the process of ExecStart= exits.
>>> If systemd can't find that file, it assumes the service has
>>> failed.
>>
>> I could directly start those daemons like I do gitlab-workhorse. But
>> I will have to duplicate all paths, as variables defined in
>> EnvironmentFile can't be used in ExecStart. Is there another way to
>> do it?
>
>Well, EnvironmentFile= variables can be used in ExecStart= (that's
>about the only place they can be used, it's not possible to use it
>in e.g. PIDFile=), HOWEVER systemd doesn't interpret shell variables
>WITHIN EnvironmentFile=. So having a line foo="${bar}/baz" won't
>work as expected.
I will try this.
>>> Beyond that I couldn't test, my VM only has 1 GiB of RAM and no
>>> swap, and that is apparently not sufficient for gitlab (unicorn
>>> complains that it's out of memory). Which seems weird to me,
>>> because this was otherwise an empty throwaway VM; an empty
>>> instance using 1 GiB of RAM seems a bit excessive if you ask me,
>>> but oh well...
>>
>> Strange to me as well because the test vm I use is just 512MB ram.
>
>Huh, I saw ENOMEM just once, maybe that was related to some other
>problem... Can't reproduce now.
>
>> I started out with using dbconfig-common but it was failing because
>> of an echo statement before I read debconf variables! I used psql
>> scripts as a work around. Now that the debconf issue is fixed, I can
>> use dbconfig-common again. Its in my TODO list.
>
>Ah, good. :)
>
>>> (Btw., off topic: I haven't done much with ruby, but gitlab pulls in
>>> build-essential via gitlab Depends: bundler and bundler Recommends:
>>> build-essential. While this is Recommends, so you can avoid it if
>>> you want to, it still seems weird to me that build-essential is
>>> pulled in by default implicitly via gitlab...)
>>
>> gem dependencies are already fragile and not having bundler would
>> make it impossible to check the dependencies.
>
>Yeah, I said I didn't know enough about ruby to make a judgment call
>on that, I just thought it weird.
>
>Thinking about it, one could possibly split bundler into two packages
>(bundler-bin and bundler), where bundler-bin contains the necessary
>libs and binaries (but the binaries not in the system PATH but rather
>in /usr/lib/bundler or so) so that you can depend on that, without
>pulling in. bundler would then be a trivial package containing only a
>symlink from /usr/bin to the real binary from the bundler-bin package,
>but the bundler package would still Recommend all that stuff. That
>way, people who want to use bundler get build-essential, whereas
>people who just want to use gitlab don't get a compiler installed.
>
>Don't know if that would be worth it (you can override Recommends:
>dependencies, so if you don't want build-essential, you can just
>remove it), but maybe you could think about it.
Thanks for the suggestion, I'll discuss with debian-ruby team.
>Regards,
>Christian
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: