Community Packages

Please read this before reporting a bug:

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!

FS#69074 - [jenkins] Reasons for limitless systemd unit configuration

Attached to Project: Community Packages
Opened by Daniel Otero (canu7) - Wednesday, 23 December 2020, 08:55 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 23 December 2020, 14:37 GMT
Task Type General Gripe
Category Packages
Status Assigned
Assigned To Felix Yan (felixonmars)
Filipe LaĆ­ns (FFY00)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


Why does the [provided]( Jenkins systemd configuration service does have some (for me) unreasonable defaults?

> OOMScoreAdjust=-1000
> LimitCPU=infinity
> LimitFSIZE=infinity
> LimitDATA=infinity
> LimitCORE=0
> LimitAS=infinity
> LimitLOCKS=infinity

This makes this service able to take down a system pretty easily, as any task executed by Jenkins (compilations, tests, whatever) will inherit the same limits. Just having a process executed by Jenkins that consumes an absurdly amount of memory will make the system trash so hard to become completely locked down requiring a hard-reset. This is because having a -1000 offset to the OOM score will make any Jenkins child process invulnerable to the kernel OOM killer.

Removing all the limits doesn't seem to impact the normal usage of Jenkins, and fixed the issue to me.

I guess my question is... Why are they there? Are they really needed?

Just trying to avoid this headaches to other users :D
This task depends upon