When installed on a modern Linux distribution running
systemd(1) service unit is delivered to:
- Red Hat
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:
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:
Description=My Company Jenkins Controller
# Add JVM configuration options
# Arbitrary additional arguments to pass to Jenkins.
# Full option list: java -jar jenkins.war --help
# Configuration as code directory
systemctl edit jenkins creates the drop-in unit as
root with 0644 (
The migration logic, on the other hand, creates the drop-in unit as
root with 0600 (
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
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
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.
systemd(1) documentation contains a table of specifiers available in unit files.