как ломануть 1C 8.3 for Linux

[vfp7]

Читал выше, что "запуск usbhasp должен быть после запуска aksusbd". Проверил, на Centos7 x64 такой проблемы нет.
Но возникла другая проблема. У меня эмулятор ключа и haspd стоят на одном сервере, а 1С стоит на другом сервере. Если отваливается процесс с эмулятором или процесс haspd (на самом деле процессы не отваливались, я вручную убил их, так как в процессе эксплуатации всякое может быть), и в этот момент кто-то пытается подключиться - соответственно он получает ошибку, что ключ не обнаружен. Дальше заново поднимаем процесс с эмулятором. Пытаемся подключиться - ошибка не уходит. Пробовал и haspd перезапускать, и порядок запуска эмулятора и haspd менял. Только перезапуск srv1cv83 помогает.
Может кто-то знает как исправить эту проблему?

Очередность старта сервисов в Ubuntu 18.04.2 x64:
1. HaspLM, aksusbd
2. UsbHasp
3. с задержкой srv1cv83
Иначе получаются ошибки вида hasp не видит ключ, или 1С не видит ключ в hasp

По Вашей проблеме - речь идет про кластер? Вы указали не полные данные что бы понять про что идет речь. Если про кластер или его гибрид, то только перезапуск srv1cv83, так как раздача ключей клиентам проходит ее средствами.

ps: разобрался с брыкающимся "Сервис сеансовых данных" в кластере (из моего прошлого поста) - можно сказать что так в 1С и должно быть. "Требования назначения функциональности" весьма специфично работает в кластере 1С, и что бы избежать недоразумений рекомендую использовать параметр "Авто", и через приоритеты выставлять желаемую очередность. Дополнительно можно ограничить потребление памяти сервису 1С в тех же настройках серверов кластера.
Так что теперь могу сказать что и на боевом сервере получил рабочую и предсказуемую 1С на ubuntu 18.04.2 x64, причем работоспособную даже в кластере.