# GlobalScheduler: частые проблемы

## algid parse error, not a sequence
При запуске `globalscheduler` в логах может возникнуть ошибка следующего вида:

```text
Job Default.22 threw a JobExecutionException: org.quartz.JobExecutionException: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: IOException : algid parse error, not a sequence
```

Чаще всего данная проблема связана с некорректным форматом приватного ключа. Для работы с `Globalscheduler` требуется 2048-битный ключ RSA формата PKCS#8. Ключи формата PKCS#1 не подходят для работы c `Globalscheduler`.

Чтобы убедиться, что ваш ключ верного формата, проверьте, что сгенерированный вами неотформатированный приватный ключ (`quartz.privatekey.txt/quartz.private.pem`) начинается со следующей строки:

```text
-----BEGIN PRIVATE KEY-----
```

В случае, если ваш ключ неверного формата (PKCS#1), он будет начинаться со следующей строки:

```text
-----BEGIN RSA PRIVATE KEY-----
```

Также проверить формат ключа можно при помощи openssl, что может быть полезно, если ключ доступен только в отформатированном для `Globalscheduler` виде (`quartz.private.txt/quarz.private.pem`), и не содержит заголовков.

Для этого используйте следующую команду, заменив значение <key_path> на путь до приватного ключа:

```bash
base64 -d <key_path> | openssl asn1parse -inform DER | grep -q rsaEncryption && echo "Ключ верного формата" || echo "Ключ неподходящего формата"
```

Чтобы сгенерировать ключ подходящего формата, воспользуйтесь генерацией пары ключей в системе Global, или следующей командой:

```bash
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048
```

## Illegal base64 character
В случае возникновения ошибки «Illegal base64 character» убедитесь, что ключи верно отформатированы. Ключи, используемые Globalscheduler, не должны содержать заголовков (-----BEGIN PUBLIC KEY-----, -----END PUBLIC KEY----- и пр.) и знаков переноса строки.

Если вы используете kubernetes, убедитесь, что файл `~/globalserver/workspace/mnt/secret/scheduler/private.key` внутри контейнера Globalscheduler содержит приватный ключ в читаемом формате (должен начинаться с букв `MIIE`).

## Плавающие ошибки Connection Refused (Kubernetes)

Если ошибка `Connection Refused` возникает непостоянно - появляется и исчезает без видимых причин - её нужно локализовать пошагово, исключая промежуточные компоненты один за другим.

### Шаг 1. Подключение напрямую к exclusive-поду, в обход прокси

Первым делом уберите из цепочки все прокси и подключите GlobalScheduler напрямую к exclusive-порту GlobalServer.

В настройках btk (Планировщик заданий) задайте:
- **HTTPS**: выключить;
- **Soap хост**: `gs-cluster-1-global-server-excl-external` (или ваше название сервиса);
- **Soap порт**: `8088`.

После изменения настроек сбросьте кеши (или перезапустите поды шедулера и серверов приложений), выполните тестовые задания и проверьте логи scheduler в Grafana.

Если ошибка не воспроизводится - переходите к шагу 2. Если воспроизводится - проблема находится внутри самого пода или конфигурации планировщика.

### Шаг 2. Подключение через внутренний HAProxy

Следующая ступень - подключение через внутренний HAProxy кластера.

В тех же настройках btk задайте:
- **HTTPS**: включить (если используется и заранее настроены cacerts);
- **Soap хост**: `gs-cluster-1-haproxy-external` (или ваше название сервиса);
- **Soap порт**: `443`.

Аналогично сбросьте кеши или перезапустите поды, выполните задания и посмотрите логи в Grafana.

Если ошибка не воспроизводится и здесь - инфраструктура кластера со своей стороны работает корректно.

### Шаг 3. Проверка внешней инфраструктуры

Если оба шага выше прошли без ошибок, проблема находится за пределами зоны ответственности кластера Global. Проверьте:
- настройки Ingress и reverse proxy;
- значения таймаутов на всех уровнях;
- конфигурацию сетевых политик;
- антивирусное ПО и межсетевые экраны, которые могут разрывать долгоживущие соединения.

## Error 401 JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted
Данная ошибка связана с тем, что установленный публичный ключ не подходит к установленному приватному ключу. Убедитесь, что установленные в Globalscheduler ключи из одной пары (в Kubernetes можно удалить под шедулера - при запуске нового в лог контейнера будет выведена информация о соответствии ключей), либо сгенерируйте новую пару ключей ([Генерация ключей шифрования](./010_scheduler_keys.md))