Приложения не запускаются при входе в систему.

Я пытаюсь разобраться, почему некоторые приложения не запускаются при входе в систему. Похоже, что это связано только с flatpak. У меня есть другие приложения, не flatpak, например virtmanager, которые запускаются нормально при входе. Я пробовал разные приложения, некоторые из них flatpak и не flatpak, но только flatpak не удается запустить. Приложения, которые не запускаются после входа в систему, работают нормально, когда я открываю их файл .desktop.

Журнал здесь мало чем помогает. Вот пример из журнала, когда приложения работали, и когда они перестали работать.

Jan 25 08:44:15 systemd[2046]: Starting [email protected] - Firefox Web Browser...
Jan 25 08:44:15 systemd[2046]: Started [email protected] - Firefox Web Browser.


Jan 26 08:38:17 systemd[2082]: Starting [email protected] - Firefox Web Browser...
Jan 26 08:38:17 systemd[2082]: Started [email protected] - Firefox Web Browser.
Jan 26 08:38:33 systemd[2082]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Jan 26 08:38:33 systemd[2082]: [email protected]: Failed with result 'exit-code'.

Приложения, файлы .desktop, запускаются из моего каталога ~/.config/autostart.

Я также попробовал использовать скрипт ~/startup.sh. Я начал с создания задания cron @boot, но это совсем не удалось. Приложение “косвенно” запускалось, как только я вводил свой пароль, и затем зависало. Поэтому я использовал функцию системных настроек для “Добавить скрипт запуска”. После перезагрузки Система Настройки и журнал просто показывали ошибку, без дополнительной информации.

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

Kubuntu Oracular 24.10 x86_64

Linux 6.11.0-14-generic

KDE Plasma 6.1.5

KWin (X11)

Думаю, вы слишком много обрезали из лога. Возможно, есть другие единицы, которые не удалось запустить, от которых зависит Firefox, например, единицы xdg-desktop-portal*.service. Но я правильно понимаю, что вы отказываетесь использовать snap Firefox? У меня с этим snap нет таких проблем. Но я подозреваю, что решение flatpak является недостаточным, обходит острые углы, например, при определении правильных зависимостей (Wants=, After=), просто догадка. Также кажется, что проблема заключается в самом framework flatpak, так как это похоже на состояние гонки, где все единицы запускаются сразу, но если единица-зависимость запаздывает, зависимая просто не удается.

Думаю, это то, что вы получаете, когда абсолютно должны игнорировать официальный подход (snap), потому что “snap плохой”.

Попробуйте:

$ alias sc="systemctl"
$ alias scu='sc --user'
$ alias sda="systemd-analyse"

Просто некоторые алиасы, чтобы уменьшить количество набора текста.

$ sda verify default.target
$ sda --user verify default.target

Есть ли сообщения типа “Ordering cycle”? Также проверьте отдельные неудачные единицы с тем же подходом, например:

$ sc list-units --failed
$ scu list-units --failed
$ sda --user verify [email protected]

Также может быть полезно

$ scu status [email protected]
$ journalctl --user -xeu [email protected]
$ scu list-dependencies [email protected]

$ scu show [email protected]

Ищите/grep подробный вывод последней команды на наличие ‘Wants=”, “Requires=”, “^.*By=’, ‘Before=”, “After=”, если необходимо, например, если предыдущие команды не дали подсказок.

И я настоятельно рекомендую перейти на версию snap Firefox. Существует много абсолютно необоснованных слухов, которые продолжают ходить, что flatpak это что-то великое, а snap осуждается как Антихрист.

И причина, по которой журнал “мало чем помогает”, может быть найдена следующим образом:

$ scu cat [email protected]

Есть ли там директива “StandardError=” или “StandardInput=”, “StandardOutput’? Любая из них может быть установлена в ‘null’, что просто игнорирует ошибки (StandardError= если не задано, наследуется от двух других, в зависимости от того, какая установлена, см. systemd.exec(5)), или какая-то другая цель логирования, например, ‘syslog’. В последнем случае, что согласуется с FUD, что journald “ест щенков”, вам придется искать эти логи. На моей стороне я вижу довольно много сообщений от snap.firefox.firefox-<some-uuid>.scope в журнале, но это нефатальные предупреждения о вещах, которые меня не волнуют. Все работает как по маслу. Также .service единица может быть не всем, как видно, что snap использует .scope единицы.

В противном случае: больше деталей, пожалуйста. Используйте вышеуказанные команды для проверки неудачных единиц перед их перезапуском, чтобы никакая информация о состоянии не была потеряна.