#5660 raise koji build timeout
Closed: Will Not/Can Not fix Opened by caolanm.

Our armv7hl LibreOffice builds appear to be getting cancelled after 24 hours building (https://koji.fedoraproject.org/koji/taskinfo?taskID=17164268). Can I get the timeout limit raise to e.g 48 hours to get around that


The timeout already is 48 hours. You are not hitting that.

Instead it looks like it hit OOM and the killer killed: kojid. :frowning:

Jan 05 05:26:43 arm02-builder02.arm.fedoraproject.org kernel: Out of memory: Kill process 7328 (kojid) score 2 or sacrifice child
Jan 05 05:26:43 arm02-builder02.arm.fedoraproject.org kernel: Killed process 7328 (kojid) total-vm:63236kB, anon-rss:16764kB, file-rss:3520kB, shmem-rss:0kB
Jan 05 05:26:34 arm02-builder02.arm.fedoraproject.org systemd[1]: kojid.service: Main process exited, code=killed, status=9/KILL

So, I am not sure what we can do here... try and get it working and hope the armv7 vm's on aarch64 we move to soon can handle this better? If there is anything we can do, please do let me know.

:broken_heart:

@kevin changed the status to Closed

I don't think this is caused by low memory on the builders: we have never seen such problem before. The last successful build of libreoffice was libreoffice-5.2.3.3-11.fc25 on Dec 3. The build of libreoffice-5.2.4.1-1.fc25 on Dec 9 did already fail. And if I try to scratch build the last successful build now, it fails as well. So, did anything change on the arm builders between these two dates?

I cannot reproduce the failure on rawhide-test.scrye.com, even limiting available memory to 2G (I'm pretty sure the koji builders have more). On f25-test.scrye.com I cannot even get far enough in the build because of insufficient disk space.

Another observation: f25 arm machines reserved from from beaker all start to behave erratically after a short use. That is, everything seems okay at first, but after a while the OOM killer suddenly starts killing almost anything one starts; not just make, but also git clone, tar -xf, dnf install,...

We are going to try the 4.9.x kernel (now in updates-testing).

If that behaves the same we should open a kernel bug and all coordinate there.

Metadata