you're right, found it later, took the slave offline.

It was a fc27 slave after all:
09:32:36 [check-patch.el7.x86_64] Running on vm0162.workers-phx.ovirt.org in /home/jenkins/workspace/vdsm_standard-check-patch

Maybe we will disconnect them meanwhile?

@Barak Korren this one failed on el7 slave, so maybe its not related to fc27?

Another failure:
https://jenkins.ovirt.org/job/vdsm_standard-check-patch/243/

On Tue, Nov 27, 2018 at 1:38 PM Eyal Edri (oVirt JIRA) <

There are quite a few fc27 slaves - http://jenkins.ovirt.org/label/fc27/
Let's verify that indeed all of them are causing issues before removing them and causing lack of resources.

Nothing on those slaves desc indicated they have an issue, so I'm not sure that was the reason they were taken offline.
In any case if they are not OK, they should be reinstalled as centos 7.
@Former user can you reinstall all the fc27 slaves as centos7?
Probably best to bring them down now ( I would but I don't have access to jenkins for some reason, I can't login )

This looks like a very old known issue - this happens when someone sets up a slave when the jenkins UID/GID are 1000.

@Eyal Edri, @Emil Natan - this seems to be all happenning on the fc27 slaves you brought up, I guess now we know why they were down in the 1st place...

@Nir Soffer WRT your 2nd issue - we actually have fixes for that where possible - but not in STDCI V1... The code structure of STDCI V1 makes this close to impossible to do there...

But for this particular issue, its not really possible to tell the difference because the failure is occurring in the innermost mock invocation that is launching your script...

@Former user can you look into it? worth marking these builds as keep forever so we can debug them later.