UniFi упал, жалуется на версию Java

Подозреваю, меня сейчас линуксоиды засмеют, но да ладно. Дано – программный UniFi-контроллер на CentOS 8, который после перезагрузки сервера отказался запускаться, аргументируя тем, что Java у него не той системы:

<launcher> ERROR launcher - Java 18 is not supported!

На всякий случай, лезем в документацию на UniFi и видим, что надо либо 17, либо 21 версию. Окай, ошибка имеет смысл, копаем дальше.

Идем смотреть, чего по этому поводу думает система

[root@xxx ~]# java -version
openjdk version "17.0.6-ea" 2023-01-17 LTS
OpenJDK Runtime Environment (Red_Hat-17.0.6.0.9-0.3.ea.el8) (build 17.0.6-ea+9-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.6.0.9-0.3.ea.el8) (build 17.0.6-ea+9-LTS, mixed mode, sharing)

Хм… Что-то тут не так… Ладненько (с)… Вспоминаем, что, вообще говоря, в рамках одного хоста могут стоят несколько версий Java. Глянем, чего там

[root@xxx ~]# update-alternatives --config java

Обнаружено 3 программ(ы), предоставляющих «java».

  Выбор    Команда
-----------------------------------------------
*+ 1           java-17-openjdk.x86_64 (/usr/lib/jvm/java-17-openjdk-17.0.6.0.9-0.3.ea.el8.x86_64/bin/java)
   2           java-21-openjdk.x86_64 (/usr/lib/jvm/java-21-openjdk-18.0.2.0.9-1.el8.x86_64/bin/java)
   3           java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.20.1.1-2.el8.x86_64/bin/java)

Enter - сохранить текущий выбор[+], или укажите номер:

Всё страньше и страньше, как говорится. Да, версий несколько – Java 11, Java 17 и Java 21. Откуда, блин, контроллер взял про 18 версию???

Внимательный читатель в последнем выводе разглядит кое-что дикое для меня. Java 11 имеет версию 11, Java 17 – версию 17. Неожиданно, правда? А вот Java 21 по какой-то непостижимой для меня причине имеет версию как раз 18! Вот хоть убейте, для меня это странно и непонятно.

Ну предположим… Делаем снапшот виртуалки, чтобы потом не было мучительно больно, и идём ставить эксперименты. Решение “в лоб” – грохнуть Java 21 и всего делов! Но, внезапно, при попытке удаления выясняется, что имеют место быть зависимости от UniFi-контроллера. В смысле при удалении Java контроллер тоже будет грохнут. Прикольно… Выяснилось также, что Java 21 принудительно ставится вместе с контроллером. В принципе, это не сильно удивляет – зависимости, все дела.

Зайдем с другой стороны – какого лешего оно пытается использовать Java 21, когда в системе по умолчанию везде стоит Java 17? Вариантов негусто – это явно прописано в настройках сервиса. Глянем, где файл с конфигурацией

systemctl status unifi
Loaded: loaded (/usr/lib/systemd/system/unifi.service; enabled; vendor preset: disabled)

Ага, вот он где. Идем смотреть и править.

nano /usr/lib/systemd/system/unifi.service

И действительно, в конфиге явно указано использовать версию 21, которая на самом деле 18

[Unit]
Description=UniFi Network Application
After=local-fs.target remote-fs.target network-online.target
Wants=network-online.target

[Service]
Type=simple
User=unifi
WorkingDirectory=/usr/share/unifi
EnvironmentFile=-/etc/sysconfig/unifi
Environment=JAVA_HOME=/usr/lib/jvm/jre-21
ExecStart=/usr/lib/jvm/jre-21/bin/java --add-opens=java.base/java.time=ALL-UNNAMED $JAVA_OPTS -jar /usr/share/unifi/lib/ace.jar start
ExecStop=/usr/lib/jvm/jre-21/bin/java $JAVA_OPTS -jar /usr/share/unifi/lib/ace.jar stop
SuccessExitStatus=143
Restart=on-success

[Install]
WantedBy=multi-user.target

Отлично! Правим “21” на “17” и сохраняем файл. После чего перечитываем данные и запускаем службу

systemctl daemon-reload
systemctl start unifi

Ура! Заработало!!!