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
Attachment:
signature.asc
Description: OpenPGP digital signature