```sh
# You may pass JVM startup parameters to Java here. If you run Tomcat with
# Java 8 instead of 9 or newer, add "-XX:+UseG1GC" to select a suitable GC.
# If unset, the default options will be: -Djava.awt.headless=true
JAVA_OPTS="-Djava.awt.headless=true"
```
Particularly, the comment states _"If unset, the default options will be: `-Djava.awt.headless=true`"._
However, the code doesn't do that; it just disregards any previous value that `JAVA_OPTS` might have had.
Rather, to reflect the intent, the code should do something along the lines of:
```sh
if [ -z "$JAVA_OPTS" ] ; then
JAVA_OPTS="-Djava.awt.headless=true
fi
```
Why is this a problem?
If a systemd unit drop-in (`/etc/systemd/system/tomcat9.service.d/override.conf`) wants to initialize `JAVA_OPTS` to a different value, that setting will currently be lost because `/etc/default/tomcat9` runs after this.
Moreover, the main `/lib/systemd/system/tomcat9.service` _also_ initializes `JAVA_OPTS`, even though it is just as futile here. I'm only guessing that this went unnoticed because it simply happens to use the same default value as `/etc/default/tomcat9`.
Ubuntu Release:
> Description: Ubuntu 22.04.3 LTS
> Release: 22.04
Package version:
> tomcat9: eu-west- 1.ec2.archive. ubuntu. com/ubuntu jammy-updates/ universe amd64 Packages dpkg/status eu-west- 1.ec2.archive. ubuntu. com/ubuntu jammy/universe amd64 Packages
> Installed: 9.0.58-1ubuntu0.1
> Candidate: 9.0.58-1ubuntu0.1
> Version table:
> *** 9.0.58-1ubuntu0.1 500
> 500 http://
> 100 /var/lib/
> 9.0.58-1 500
> 500 http://
Offending section from `/etc/default/ tomcat9` :
```sh awt.headless= true "-Djava. awt.headless= true"
# You may pass JVM startup parameters to Java here. If you run Tomcat with
# Java 8 instead of 9 or newer, add "-XX:+UseG1GC" to select a suitable GC.
# If unset, the default options will be: -Djava.
JAVA_OPTS=
```
Particularly, the comment states _"If unset, the default options will be: `-Djava. awt.headless= true`". _
However, the code doesn't do that; it just disregards any previous value that `JAVA_OPTS` might have had.
Rather, to reflect the intent, the code should do something along the lines of:
```sh OPTS="- Djava.awt. headless= true
if [ -z "$JAVA_OPTS" ] ; then
JAVA_
fi
```
Why is this a problem?
If a systemd unit drop-in (`/etc/ systemd/ system/ tomcat9. service. d/override. conf`) wants to initialize `JAVA_OPTS` to a different value, that setting will currently be lost because `/etc/default/ tomcat9` runs after this.
Moreover, the main `/lib/systemd/ system/ tomcat9. service` _also_ initializes `JAVA_OPTS`, even though it is just as futile here. I'm only guessing that this went unnoticed because it simply happens to use the same default value as `/etc/default/ tomcat9` .