Re: migrating to Debian gitlab
On 2016, ഫെബ്രുവരി 15 9:00:26 PM IST, Christian Seiler <christian@iwakd.de> wrote:
>On 02/15/2016 03:42 PM, Pirate Praveen wrote:
>> While trying to move files that are created at runtime to /var, I
>> realized /var/run/gitlab won't persist across reboots.
>
>Well, thats kind of the semantics it was designed for: /run (formerly
>/var/run, which is now a symlink to /run) is not supposed to be
>persistent. Persistent data should typically go into /var/lib or
>/var/cache.
We are using /run for pid/socket files only.
>> I have added a RuntimeDirectory=gitlab option to gitlab
>> service files, but gitlab-unicorn can't stay alive. It
>> starts and writes /run/gitlab/unicorn.pid but dies without
>> any log message in /var/log/gitlab/unicorn.stderr.log. No
>> useful message on jornalctl -xe either. Can anyone help?
>
>You're pid file logic is broken:
>
> - gitlab-workhorse.service says /run/gitlab/gitlab-workhorse.pid,
> but ExecStart= uses /run/gitlab/pids/gitlab-workhorse.pid as
> the argument - and since /run/gitlab/pids doesn't exist, that
> service fails (pass /run/gitlab/gitlab-workhorse.pid as the
> argument in ExecStart= and that problem goes away)
It is already fixed in git, but it is not enough to solve the problem. gitlab-unicorn.service is not starting.
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.
> - 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.
> (which btw. violates Debian policy, /usr should never be
> modified during normal program execution [1]).
Working on moving all those to /var.
>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?
>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.
Also I remember reading about someone willing to offer machines for debian work. Is it GPLHost?
The current vps I use for testing is on openvz and can't have systemd. I have to stop X to be able to run gitlab on my 2GB ram laptop.
>> Please build the package from git.
>
>Note that your Vcs-Git URI is wrong (hence debcheckout gitlab doesn't
>work), there's a /git/ missing in the path.
>
>Btw. if you have policy-rc.d with exit 101 installed, you can't
>install the gitlab package, because it tries to configure a local
>database and that isn't started at that point. You really shouldn't
>fail here but provide some other option (I don't know what would be
>best in this case) - and you should use dbconfig-common for the
>database stuff - because that unifies database configuration
>(especially for web stuff) in Debian and most admins probably know
>about it and can configure it to their liking. (For example, you
>might want to run the database server on another computer,
>dbconfig-common supports that out of the box.)
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.
>Regards,
>Christian
>
>(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.
>[1] I also noted that all files in /usr/share/gitlab belong to the
>gitlab user, which means that gitlab could in principle replace the
>code there. This is problematic from a Debian policy point of view.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: