When installed on a modern Linux distribution running systemd(1), the systemd(1) service unit is delivered to:
- Debian
-
/lib/systemd/system/jenkins.service
- Red Hat
-
/usr/lib/systemd/system/jenkins.service
- openSUSE
-
/usr/lib/systemd/system/jenkins.service
The main service unit is read-only and not intended to be edited manually.
It contains a large notice at the top of the file reminding the user that it is read-only.
Values may be overridden in the drop-in unit (override.conf file) for the service.
Edit the drop-in unit with:
The override.conf file is stored at /etc/systemd/system/jenkins.service.d/override.conf and can be used to customize the service.
Note that such customizations must be done in a [Service] section in order to take effect.
Example content of the override.conf file might include:
[Unit]
Description=My Company Jenkins Controller
[Service]
# Add JVM configuration options
Environment="JAVA_OPTS=-Djava.awt.headless=true -XX:+UseStringDeduplication"
# Arbitrary additional arguments to pass to Jenkins.
# Full option list: java -jar jenkins.war --help
Environment="JENKINS_OPTS=--prefix=/jenkins --javaHome=/opt/jdk-11"
# Configuration as code directory
Environment="CASC_JENKINS_CONFIG=/var/lib/jenkins/configuration-as-code/"
|
|
systemctl edit jenkins creates the drop-in unit as root with 0644 (-rw-r—r--) permissions.
The migration logic, on the other hand, creates the drop-in unit as root with 0600 (-rw-------) permissions.
This might be of consequence if you store an HTTPS keystore location and/or password in the drop-in unit
and also run jobs directly on the controller,
a practice which the Jenkins project explicitly discourages.
When in doubt, secure the drop-in unit by setting its permissions to 0600 with chmod(1).
|
The drop-in unit unifies configuration across all three distributions: Debian, Red Hat, and openSUSE.
Also note that the drop-in unit is not overwritten on upgrades.
|
|
Unlike the System V init(8) configuration, the override.conf file only contains customizations, not the original defaults.
Users who are accustomed to editing an existing set of defaults must refer to the (read-only) service unit side-by-side when editing the drop-in unit
or use a command like systemctl edit jenkins --full, which copies the original service unit instead of creating a drop-in unit.
|
Editing the drop-in unit with systemctl edit jenkins will automatically reload the systemd(1) configuration.
The settings will take effect the next time Jenkins is restarted.
If you edit the drop-in unit without systemctl(1), you need to run systemctl daemon-reload for the changes to take effect.
A final point to mention about the service unit is its use of specifiers,
which may be unfamiliar to some users.
The drop-in unit does not perform shell expansion.
Specifiers can insert contextual information (like system hostname, unit name, and operating system kernel release) into the drop-in unit.
The systemd(1) documentation contains a table of specifiers available in unit files.