Alauda Build of SonarQube Docs
  • Русский

    • Ошибка загрузки сканирования: IOException: The temporary upload location is not valid

    Содержание

    Описание проблемыКорневая причинаДиагностикаШаг 1 — Подтвердите симптом в web.logШаг 2 — Проверьте состояние каталога внутри PodРешениеВариант A — Воссоздать каталог на местеВариант B — Перезапустить Pod SonarQubeПримечания

    Описание проблемы

    Когда CI pipeline (или ручной запуск sonar-scanner) отправляет отчет сканирования в SonarQube, загрузка завершается с HTTP 500 от endpoint /api/ce/submit, а в web.log SonarQube отображается:

    java.io.IOException: The temporary upload location [/opt/sonarqube/temp/tc/work/Tomcat/localhost/ROOT] is not valid
        at org.apache.catalina.connector.Request.parseParts(Request.java:2530)
        ...

    Анализ так и не попадает в очередь на странице Background Tasks. Сам пользовательский интерфейс SonarQube остается доступным для других операций — сбой относится только к приему новых отчетов сканирования, которые содержат multipart-файл report.

    В более ранних версиях SonarQube та же первопричина иногда проявлялась как ответ HTTP 400 с сообщением ERROR: The report parameter is missing. Процедура восстановления ниже одинакова в обоих случаях.

    Корневая причина

    Веб-уровень SonarQube встраивает Tomcat (org.sonar.server.app.EmbeddedTomcat) и сохраняет загруженный файл отчета как multipart-временную загрузку, прежде чем передать его в Compute Engine. Временное расположение находится в рабочем каталоге Tomcat:

    /opt/sonarqube/temp/tc/work/Tomcat/localhost/ROOT/

    Если этот каталог не существует (что часто происходит после ручного изменения внутри Pod, после частичного восстановления volume или когда из-за некорректно настроенного mount часть дерева temp была заменена), Tomcat отказывается разбирать multipart-запрос и выбрасывает IOException: The temporary upload location [...] is not valid до того, как вызывается контроллер SonarQube. HTTP 500 затем возвращается обратно в scanner.

    Диагностика

    Шаг 1 — Подтвердите симптом в web.log

    kubectl -n <NAMESPACE> exec <RELEASE>-sonarqube-xxxxx -- \
  tail -200 /opt/sonarqube/logs/web.log

    Стек вызовов, содержащий The temporary upload location и Request.parseParts, является диагностическим признаком. Если в журнале отображается другая ошибка (сбой аутентификации, неизвестный проект, несоответствие версии scanner), эта запись не применима.

    Шаг 2 — Проверьте состояние каталога внутри Pod

    kubectl -n <NAMESPACE> exec <RELEASE>-sonarqube-xxxxx -- \
  ls -ld /opt/sonarqube/temp/tc/work/Tomcat/localhost/ROOT/
    • Если путь не существует, проблема применима.
    • Если путь существует, но его владелец не соответствует runtime UID/GID процесса SonarQube, проблема также применима. В стандартном image Pod запускается с runAsUser: 1000 / runAsGroup: 1000, а существующие файлы в temp/tc принадлежат 1000:1000 (группа выводится числом, поскольку в /etc/group этого image нет записи для gid 1000).

    Решение

    Выберите один из двух вариантов ниже.

    Вариант A — Воссоздать каталог на месте

    Воссоздайте отсутствующий каталог внутри Pod и восстановите владельца, чтобы процесс SonarQube мог в него записывать:

    kubectl -n <NAMESPACE> exec <RELEASE>-sonarqube-xxxxx -- bash -lc '
  mkdir -p /opt/sonarqube/temp/tc/work/Tomcat/localhost/ROOT/
  chown -R 1000:1000 /opt/sonarqube/temp/tc
'

    Повторно запустите неудачное сканирование. Теперь загрузка должна вернуть HTTP 200 с taskId, а анализ должен появиться на странице Background Tasks.

    Вариант B — Перезапустить Pod SonarQube

    Поскольку /opt/sonarqube/temp при запуске SonarQube создается заново с нуля, перезапуск Pod дает тот же эффект, что и вариант A, и позволяет избежать ручного редактирования файлов внутри работающего контейнера:

    kubectl -n <NAMESPACE> rollout restart deployment <RELEASE>-sonarqube

    Дождитесь, пока новый Pod перейдет в состояние Ready, затем повторно запустите scan.

    Примечания

    • Не монтируйте поверх /opt/sonarqube/temp. Этот путь является временной рабочей областью и не должен поддерживаться persistent volume или заменяться emptyDir из другого контейнера. Если поверх него был добавлен пользовательский mount, его удаление является постоянным исправлением; варианты A и B лишь временно устранят симптом до следующего перезапуска Pod.

    • Давление на диск. Если каталог temp продолжает исчезать или попытки записи продолжают завершаться неудачей даже после того, как каталог создан, проверьте, не закончился ли объем доступного места в writable layer Pod (или в volume, смонтированном в /opt/sonarqube/temp, если он есть).

    • Следующие термины не переводить:

      • ACP
      • Alauda Build of SonarQube
      • Administrator
      • Marketplace
      • Operator Hub