Автозапуск и авторестарт Qt Gui Application в Linux

Опиши ситуацию точнее. Это домашний комп или что-то типа общедоступного киоска?

Если второе, то nodm запускает WM, а WM запускает уже скрипт, что запускает приложение и перезапускает его при падении.

Опиши ситуацию точнее. Это домашний комп или что-то типа общедоступного киоска?

У меня есть ПК на работе. На нем поставил виртуальную машину(VM). В ней сейчас и эксперементирую.

До этого экспериментировал без виртуальной машины. Дошел до того, что было loop login, что не мог стартовать визуальную оболочку...

Если второе, то nodm запускает WM, а WM запускает уже скрипт, что запускает приложение и перезапускает его при падении.

К сожалению, я не уловил суть. Я в Linux совсем новичок. Не могли бы подробнее написать?

QXcbConnection: Could not connect to display
Переменная DISPLAY установлена

Вангую 99% что она устанавливается уже ПОСЛЕ того, как идёт попытка запуска прожки. ЯННП что у тебя где, так что сам ещё раз прошурши что и в каком порядке дёргается.

Смотри: в Linux есть runlevel, прочти про них подробнее. На 3 загружается многопользовательская система, на 5 стартует графика. Как уже написали выше, у тебя приложение пытается запуститься до того, как стартует графическая подсистема (и установится переменная DISPLAY), она в Unix не является обязательной.

Порядок загрузки на десктопе примерно такой: сперва 3 runlevel, потом на 5 стартует Xserver, потом DM (display manager) запускает WM (window manager), а он грузит DE (desktop environment), причем последнее — не всегда. С Wayland и GNOME 3 хитрее.

Да, и сюрприз: звуковая подсистема ALSA запускается независимо от графической подсистемы. А уже поверх неё обычно PulseAudio — хотя это не обязательно.

Это не совсем точно, на деле несколько хитрее, я сам не то что бы гуру.

Спасибо за интересную информацию. Примерно думал в это направление, теперь стало более понятно.

Сейчас у меня фокус сместился с автозапуска просто на запуск. Т.е. сейчас я нахожусь в системе. Т.е. уже все уровни запущены. Вхожу:

sudo supervisor

supervisor> start long_script

tail /var/log/long.err.log

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.screen: QXcbConnection: Could not connect to display 
Could not connect to any X display.

У меня GNOME.

Сделай шелл-скрипт с запуском после падения в цикле, и запускай через десктопную быдлоавтозагрузку

Порядок загрузки на десктопе примерно такой: сперва 3 runlevel, потом на 5 стартует Xserver
Это не совсем точно

Точнее старт идёт в ранлевел 3, или в ранлевел 5. Или у какой-то другой. Переход из одного в другой не последовательный, а с выходом из текущего. И это касается sysvinit, с другими системами инициализации может происходить иначе.

Насчет авторестарта - почему бы не сделать бесконечный цикл в скрипте запуска?

cd /path/to/prog
while true; do
  ./prog
  sleep 3
done

Лол комментаторам. Display это обычная переменая окружения. У супервизора оно одно, у с-д другое. Делай или отдельное приложение, которое будет запускать твое приложение или как предложили ниже колхозь его же на баше

Автозапуск это что то типа .config/autostart для гуйни

Спасибо. После многих попыток было решено пользоваться автозапуском скрипта, содержащим бесконечный цикл. Основа похожа на приведенный код. Добавлена еще логика и ветвление - если завершилось корректно(вернулся 0) или нет.

Насчет не скриптового варианта. Докопался до правильного вопроса :)

Linux give X server sesion to root

Одно из обсуждений.

Суть в том, что в приведенных утилитах как-то получается, что они стартуются из-под root'a и программа запускается из под root'a.

В саму систему я заходил как обычный пользователь. Начинаю понимать, что под пользователя создалась сессия X server'a. X server в моём понимание - это модуль Linux, который отвечает за графический интерфейс. И если у запускаемой программы есть интерфейс, то он отрисуется с помощью этого X server модуля. Он стартуется на каком-то этапе старта системы и создает сессию для пользователя.

Что имеем. Пользователь с сессий. Можно пользователем спокойно вручную запустить графическую программу. И нельзя запустить программу через утилиту, т.к. запуститься через root(супер пользователя), у которого своей сессии нет.

Дать бы root'у возможность пользоваться этой сессией пользователя, но с этим какой-то облом.

В рамках получения доступа к экрану(сессии) по ssh с другого компа это как-то разруливается через xhost как пишут в интернетах.

Еще пишут, что пользоваться sudo для запуска графического приложения плохо. На то есть gksudo. Хорошо. Попробовал и его. Всё-равно не получилось.

Попробовал в утилитах, чтобы старт был от пользователя. Всё-равно не получилось.

Поэтому и было решено перейти к скрипту с минимальной логикой.