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.
>> - 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
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.
>> 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.
>> 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.
Regards,
Christian
signature.asc
Description: OpenPGP digital signature
