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. > 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) - 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 (which btw. violates Debian policy, /usr should never be modified during normal program execution [1]). 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. 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... > 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.) 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...) [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.
Attachment:
signature.asc
Description: OpenPGP digital signature