I have just spent about 2 hours to figure out why my GitLab CE (on my home server) won’t boot. Luckily I am quite alright at searching for things on the internet - which is how I found out how to look for a culprit.
This is not exactly a bug report as I cannot tell if it actually was a bug to begin with and I have no idea how to reproduce it (perhaps if I reboot my server… but I am not sure the problem will persist).
My problem: the GitLab CE installation on my server was not reachable (other applications such as SonaType Nexus were - as well as the server over SSH and xRDP). After some fiddling and reading I found out, that gitlab-runsvdir.service was not running - it was loaded / inactive / dead.
I ran sudo systemctl -t target and found out, that multi-user.target and graphical.target were loaded, inactive and dead. sudo systemctl list-jobs showed quite a few jobs, which apparently were waiting - plymouth-quit-wait.service was start running while all the others were start waiting (gitlab-runsvdir.service was among them, too).
After killing the plymouth-process, GitLab started just fine. Of course I was clueless and I am a developer and less of a Linux professional - which is why it probably took me so long. I found this question Slow boot issue due to plymouth-quit-wait.service + ubuntu 18.04 - Ask Ubuntu stating the matter in a slightly more abstract way.
I scanned through various pages in the official GitLab documentation, read about a few issues, which seem to all have been fixed. Sure - I was on some version 12.9.x of GitLab-CE/-EE (not sure which one, but I don’t pay a subscription fee, so I guess it’s the former), so an issue might have been still there. It figures it was such a small thing - plymouth - that I decided to post here in order to perhaps save someone some headache at some point.
Great software and awesome community (I had been reading on here for a while on and off, but usually never wrote anything - until now).
Thank you for your post, it really helps.
I was installing Nvidia driver and CUDA earlier today, rebooted my server serveral times while installing and ran into the same problem. My GitLab wouldn’t start and did not output any infomation, while other applications were running just fine. I tried to kill the plymouth-quit-wait service, and my GitLab was back to life.
Still don’t know why the plymouth-quit-wait preventing gitlab to start. It might be that gitlab-runsv.service depends on multi-user.target. But disable the service or uninstall plymouth and this problem won’t happen any more.
Yeah, the issue seemed, that for some odd reason plymouth-quit-wait hung. Due to lack of knowledge I can only speculate, that (as mentioned in my previous post) the GitLab service seemed to depend on graphical.target - which it probably shouldn’t. I do not know how it ended up depending on that, but perhaps removing this dependency would solve the issue, too.
Since I moved to GitLab in Docker, I haven’t encountered this problem again though, but countless other difficulties.
Old post, but I also ran into this today. Latest gitlab, on ubuntu 24.04, installed 22.04 version of gitlab since they don’t have 24.04 yet.
I started off with having a monitor/etc attached with this new server, but then moved it to the rack. Now the systemctl list-jobs is showing several waiting (including the gitlab-runsvdir.service), with plymouth-quit-wait.service running.
Soon as i killed the plymouth process everything unleashed fine.
I dont think gitlab should be dependent on graphical.target
gitlab-runsvdir.service
○ └─multi-user.target
○ └─graphical.target
Some other ubuntu thread tried to claim that plymouth runs asyncronously, not blocking anything, but clearly not the case.
Gitlab isn’t dependent on graphical.target. Rather your system is configured to run the graphical target. Ideally, change the default target to the multi-user one, and then your graphical environment won’t start.
The problem here isn’t Gitlab, but rather your system and the plymouth-quit-wait service. You need to be searching for reasons why plymouth-quit-wait service isn’t starting/stopping properly.