xfce4-clipman требует доступа к вашему дисплею Xorg (графическая система X11) - не только потому, что это действительно графическое приложение, но и потому, что это менеджер буфера обмена, и X11 покрывает это.
(Основная) проблема: ваш дисплей Xorg на самом деле еще не доступен при запуске. Он запускается при входе в систему через некоторое время после запуска системы. Поэтому невозможно запустить xfce4-clipman «при запуске» - на самом деле вы хотите запустить приложение и при входе в систему.
(Linux создан для поддержки нескольких пользователей, которые могут входить и выходить из системы в любое время - каждый пользователь запускает совершенно новую копию Xorg, а сам экран входа в систему также получает ее. Поэтому службы не могут рассчитывать на то, что Xorg будет доступен на все. )
Запуск приложений при входе в систему
Большинство окружений рабочего стола, включая Xfce, могут запускать задачи входа в систему через *.desktopфайлы (именно так запускаются различные компоненты Xfce).
Они расположены как /etc/xdg/autostart/для глобальных услуг, так и ~/.config/autostart/для личных. После создания он по умолчанию «включен», хотя все еще может быть отключен с помощью xfce4-session-settings.
Фактически, даже xfce4-clipman устанавливает свой собственный файл автозапуска в / etc / xdg / autostart - он называется xfce4-clipman-plugin-autostart.desktop. Он должен работать автоматически, если вы используете Xfce4 (из-за OnlyShowIn=XFCEстроки).
Но если в вашей системе отсутствует этот файл или если вы хотите использовать xfce4-clipman в среде, отличной от Xfce, то вы можете создать новый. .desktopФайлы автозапуска обычно выглядят так:
[Desktop Entry] Type = Application Имя = Менеджер буфера обмена Exec = xfce4-clipman Terminal = ложь
Запуск не-CLI программ вручную
Во многих средах рабочего стола есть диалоговое окно «Выполнить» AltF2, которое позволяет запускать программы, не занимая терминал.
Различные способы сделать то же самое из терминала:
(setsid xfce4-clipman 2>/dev/null &)(xfce4-clipman &)nohup xfce4-clipman &xfce4-clipman & disown- и так далее.
Другие проблемы с вашим скриптом init.d
В ситуациях, когда системные службы являются подходящими, вы должны помнить, что файлы в /etc/init.d - это не просто простые сценарии, они также запускаются при завершении работы и должны принимать подкоманды, такие как «stop» или «restart». Когда системные вызовы /etc/init.d/your_service stop, initscript должен фактически остановить службу - не запускать ее снова!
Вы пометили вопрос с помощью systemd, так почему бы не сэкономить много хлопот и *.serviceвместо этого написать собственный системный файл? В то время как «правильные» сценарии init.d могут заполнять несколько экранов, системные службы .services часто содержат менее десятка строк.
Еще более важно то, что в различные моменты времени существует множество десятков сервисов. На более поздних этапах доступны некоторые возможности, которых на более ранних этапах нет. (Например, сеть.)
Если в вашем начальном сценарии не указаны явные требования к упорядочению («должен выполняться до Y, но после Z»), ОС запустит его на непредсказуемой стадии, параллельно со всем остальным. Если вам очень повезет, он запустится в нужный момент, но в большинстве случаев он будет запускаться слишком рано, чтобы что-то сработало.
В нативных Systemd единичных файлов, упорядочение задается с помощью Before=и After=параметров. (Рекомендуется также указывать зависимости с помощью Requires=или Wants=.) Между тем, сценарии init.d (как с SysVinit, так и с systemd) используют специальный помеченный блок комментариев ### BEGIN INIT INFOс параметрами, такими как Required-Start:и Should-Start:.