LINUX.ORG.RU

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

 , , ,


0

1

Здравствуйте, дорогие форумчане!

Задача - запускать приложение с интерфейсом при старте системы и запускать, если оно вдруг упадет.

У меня Debian 9.5.

Сначала пробовал systemd. Переделал простой пример.

Не получилось. journalctl выдал:

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

По мере изучения вопроса я понял, что systemd хорошая утилита. Но она не предназначена для работы с программами с GUI.

Посмотрел в сторону обычной автозагрузки - Desktop Entry Files. Прекрасная рабочая статья.

Автозагрузка прошла успешно. Но мне нужен еще и рестарт программы при её закрытие, крушение. Достичь рестарта тут не получилось.

Посмотрел в сторону supervisor. Думал, что она меня спасет. Но нет. После переделывания тестового примера и попытки запуска получил тоже:

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

Вот мой скрипт:

Файл: /usr/local/bin/long.sh                       

#!/bin/bash
/opt/control_block/b/bin/control_block

Вот кофиг:

Файл: /etc/supervisor/conf.d/long_script.conf

[program:long_script]
command=/usr/local/bin/long.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/long.err.log
stdout_logfile=/var/log/long.out.log

Приписывал в скрипт sudo, gksudo - не запускается всё-равно. Не могли бы помочь, почему не хочет подключиться к X-Server?

Вручную запустить могу и под юзером и под root. Переменная DISPLAY установлена.

Здесь говорится о такой проблеме. Приводится код для устранения. Но и упоминается, что это:

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

всего-лишь warning.

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

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

Vsevolod-linuxoid ★★★★★ ()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

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

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

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

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

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

avovana ()

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от avovana

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

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

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

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

Vsevolod-linuxoid ★★★★★ ()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от Vsevolod-linuxoid

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

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

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.

avovana ()
Ответ на: комментарий от Vsevolod-linuxoid

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

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

AS ★★★★★ ()

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

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

arcanis ★★★★ ()
Ответ на: комментарий от arcanis

Спасибо. После многих попыток было решено пользоваться автозапуском скрипта, содержащим бесконечный цикл. Основа похожа на приведенный код. Добавлена еще логика и ветвление - если завершилось корректно(вернулся 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. Хорошо. Попробовал и его. Всё-равно не получилось.

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

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

avovana ()