On Fri, Apr 03, 2020 at 06:26:23PM +0200, Andrea Bolognani wrote: > Looks like I somehow sent an empty reply by mistake the first time > around. Let's try again... > > On Fri, 2020-04-03 at 16:04 +0200, Erik Skultety wrote: > > On Fri, Apr 03, 2020 at 03:50:21PM +0200, Andrea Bolognani wrote: > > > I have tested this, though not extensively, on Linux and adding > > > User=gitlab to the service file seems to be basically all that's > > > > Did ^this actually work? I recall having some issues on Linux when I used the > > User= directive and I could not get the agent pull a job from the server, > > It would seem that way: > > https://gitlab.com/abologna/libvirt/pipelines/132661098 Sorry, what exactly am I looking at ^here? Those are all containers, whereas these patches are targeting VMs mainly. Anyhow, now I remember why I didn't go with User=gitlab systemd service directive and opted for dropping the privileges by gitlab-runner itself, the build fails on debian-9: https://gitlab.com/eskultety/libvirt/-/jobs/498107944 ..so far, I haven't been able to identify the problem on debian. In fact, if I create the directory forcefully, I get: https://gitlab.com/eskultety/libvirt/-/jobs/499941944 ...which is even weirder because it doesn't tell me anything and not even debug messages on gitlab-runner reveal what the issue is, it just "fails the job" Centos-7 (identical setup): https://gitlab.com/eskultety/libvirt/-/jobs/498107857 FreeBSD: https://gitlab.com/eskultety/libvirt/-/jobs/498107686 -- Erik Skultety
