Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#49193 - [gitlab] gitlab won't start

Attached to Project: Community Packages
Opened by Simon Hanna (simonsmiley) - Tuesday, 03 May 2016, 14:46 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Monday, 23 May 2016, 15:40 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I'm not sure what has been changed when the package moved from aur to community.
I figured out that the user was changed from gitlab to git. (Why? I had to change ownerships of files throughout the system!)

* My database.yml file was pacsaved
* Sidekiq won't start because it can't find my database.yml (After restoring it)
* Unicorn won't start for no obvious reason
* I have no /run/gitlab directory (It get's removed if I create it manually)
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Monday, 23 May 2016, 15:40 GMT
Reason for closing:  Fixed
Comment by Simon Hanna (simonsmiley) - Tuesday, 03 May 2016, 14:48 GMT
I'm currently running gitlab revision 4 and gitlab-shell revision 5

Also why are you not running the database migrations automatically? I really don't know why you changes so much. I thought the upgrade was safe because it was just a security fix, now I don't have a running gitlab installation and at this point, I'm too afraid to start reverting the changes I already did...
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 03 May 2016, 14:56 GMT
You have to look at the gitlab packages in [community] and AUR as separate entities without an automatic upgrade path between them. Migrations aren't automatically run because we don't want to automatically change a user's database as it might be potentially dangerous. I'll look into why there is no /run/gitlab.
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 03 May 2016, 15:01 GMT
What are the contents of your /usr/lib/tmpfiles.d/gitlab file?
Comment by Simon Hanna (simonsmiley) - Tuesday, 03 May 2016, 15:02 GMT
I don't have a gitlab file there
Comment by Sven-Hendrik Haase (Svenstaro) - Tuesday, 03 May 2016, 15:04 GMT
Then your installation is messed up. This file should exist on a proper gitlab installation of the package in [community].
Comment by Simon Hanna (simonsmiley) - Tuesday, 03 May 2016, 15:53 GMT
Ah, I just did a cat earlier, now I figured out that it's gitlab.conf
The contents match the file in the package.
I now downgraded to the aur version.
What "upgrade" path do you recommend if I want to switch to community?
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 06 May 2016, 12:12 GMT
I can't recommend an upgrade path as I don't know what the old package did. I would just do a backup of all repositories, config and database (perhaps using the built-in functionality) and then nuke everything that is Gitlab in the system. Then install the official gitlab package and put the backup stuff back in place.
Comment by Janne Heß (das_j) - Tuesday, 17 May 2016, 20:54 GMT
@Svenstaro Look at RuntimeDirectory in service units (http://man7.org/linux/man-pages/man5/systemd.exec.5.html).
This might obsolete your tmpfiles approach.
Comment by Sven-Hendrik Haase (Svenstaro) - Monday, 23 May 2016, 15:40 GMT
Thanks Janne, but I think the lifetime guarantee is enough here. gitlab runs a bunch of service and if I understand correctly, the runtime directory goes away if the service is killed. I would like to stick multiple services into that directory, however.

Anyway, about this bug, I think gitlab in [community] now is a in a sufficiently good state that we can close this bug. I know it's working quite well for me, at least.

Loading...