1. включаю Lightdm: echo LDM > /etc/sysconfig/desktop 2. service dm restart Lightdm не стартует. strace на rundm показывает: 13510 13:21:51 execve("/usr/sbin/lightdm", ["lightdm", "-nodaemon"], [/* 33 vars */]) = 0 [...] 13510 13:21:51 write(2, "Unknown option -nodaemon\n", 25) = 25 13510 13:21:51 write(2, "Run 'lightdm --help' to see a fu"..., 74) = 74 Оно вообще работает?
Подозреваю, что проблема не в этом. Рискну предположить что используется systemd, и параметр -nodaemon получается из prefdm.service. Попробуй скопировать /lib/systemd/system/prefdm.service в /etc/systemd/system, убрать в нём -nodaemon и перезапустить сервис.
(В ответ на комментарий №1) > Подозреваю, что проблема не в этом. > Рискну предположить что используется systemd Смело, но нет, ни разу не systemd. Обычный init.d. Обычный Сизиф+ GNOME 3.2. gdm в нём не запускается, поэтому пошёл искать альтернативы. Мне кажется, что проблему легко расковырять, запустив рутом вот это: strace -fto /tmp/rundm.stra rundm посмотри, что там rundm execve-ит.
Опция "-nodaemon" добавляется здесь: http://git.altlinux.org/gears/x/xinitrc.git?p=xinitrc.git;a=blob;f=xinitrc/src/rundm.c#l46 gdm и kde ее понимают, lxdm ее просто игнорирует
(В ответ на комментарий №3) > Опция "-nodaemon" добавляется здесь: > http://git.altlinux.org/gears/x/xinitrc.git?p=xinitrc.git;a=blob;f=xinitrc/src/rundm.c#l46 > > gdm и kde ее понимают, lxdm ее просто игнорирует -nodaemon понимает только xdm. остальные все игнорируют, у кого-то это получается лучше, у кого-то хуже. gdm пытаясь игнорировать, выцепляет "d" и включает debug. lightdm сейчас себя ведёт также. Перевешиваю я багу на xinitrc с просьбой не добавлять этот параметр. Возможно лучше добавлять -nodaemon только для xdm внутри prefdm.
(В ответ на комментарий №4) > -nodaemon понимает только xdm. > остальные все игнорируют Не говорите за всех. kdm-ы тоже понимают
Еще раз прошу адаптировать rundm для gdm и lightdm. Прошу передавать "-nodaemon" только для xdm и kdm. Уже несколько лет gdm работает в режиме debug, с этим надо что-то делать.
/etc/X11/prefdm на данный момент поддерживает 8 dm'ов. Для каждого из них нужно определить, нужен -nodaemon или нет.
(В ответ на комментарий №7) > /etc/X11/prefdm на данный момент поддерживает 8 dm'ов. > Для каждого из них нужно определить, нужен -nodaemon или нет. xdm - поддерживает kdm - поддерживает wdm - поддерживает gdm - не поддерживает, реагирует на "-d" и включает debug mdm - не поддерживает, реагирует на "-d" и включает debug lightdm - не поддерживает. , реагирует на "-d" и включает debug. Специально патчится чтобы не падать с "-nodaemon" entrance - "--nodaemon" или "-n". Специально патчится чтобы не падать с "-nodaemon" lxdm - в аргументах "-D" - debug, а "-d" - daemon, так что -nodaemon скорее всего работает ровно наоборот.
(В ответ на комментарий №8) > gdm - не поддерживает, реагирует на "-d" и включает debug gdm, который gdm2.20 - поддерживает. Для gdm 3.6 в gentoo есть патч: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/gnome-base/gdm/files/gdm-3.6.0-fix-daemonize-regression.patch?view=log > mdm - не поддерживает, реагирует на "-d" и включает debug mdm, который mint-display-manager - умеет (потому что это gdm 2.20). И я не уверен, что mdm, который mate-d-m еще кому-то интересен.
(В ответ на комментарий №9) > (В ответ на комментарий №8) > > gdm - не поддерживает, реагирует на "-d" и включает debug > > gdm, который gdm2.20 - поддерживает. > Для gdm 3.6 в gentoo есть патч: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/gnome-base/gdm/files/gdm-3.6.0-fix-daemonize-regression.patch?view=log > > > mdm - не поддерживает, реагирует на "-d" и включает debug > > mdm, который mint-display-manager - умеет (потому что это gdm 2.20). > И я не уверен, что mdm, который mate-d-m еще кому-то интересен. Ок, ошибся. Всем кажется, что надо патчить все *dm для поддержки -nodaemon? Мне кажется в апстримы вообще лучше поменьше вмешиваться.
(In reply to comment #10) > (В ответ на комментарий №9) > > (В ответ на комментарий №8) > > > gdm - не поддерживает, реагирует на "-d" и включает debug > > > > gdm, который gdm2.20 - поддерживает. > > Для gdm 3.6 в gentoo есть патч: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/gnome-base/gdm/files/gdm-3.6.0-fix-daemonize-regression.patch?view=log > > > > > mdm - не поддерживает, реагирует на "-d" и включает debug > > > > mdm, который mint-display-manager - умеет (потому что это gdm 2.20). > > И я не уверен, что mdm, который mate-d-m еще кому-то интересен. > Ок, ошибся. > Всем кажется, что надо патчить все *dm для поддержки -nodaemon? Если $dm из одного пакета требует указания -nodaemon, а из другого - не поддерживает -nodaemon, то для того, чтобы их различать, в /etc/sysconfig/desktop придется записывать разные слова. Например, если GNOME это gdm из gnome3, то -nodaemon не нужен, а если это gdm2.20, то -nodaemon нужен, т.е. одного слова GNOME уже получается недостаточно. Вообще вся эта архитектура prefdm устарела, конечно.
(В ответ на комментарий №11) > Если $dm из одного пакета требует указания -nodaemon, а из другого - не > поддерживает -nodaemon, то для того, чтобы их различать, в > /etc/sysconfig/desktop придется записывать разные слова. Например, если GNOME > это gdm из gnome3, то -nodaemon не нужен, а если это gdm2.20, то -nodaemon > нужен, т.е. одного слова GNOME уже получается недостаточно. Если менять, то для gdm2.20. Особенно учитывая, что с современным гномом он, возможно, вообще не работоспособен.
(В ответ на комментарий №11) > Вообще вся эта архитектура prefdm устарела, конечно. Ну так может обновим эту архитектуру? Сразу только не кричите, что еще пользуются sysv :) Дайте сначала прикинуть. Если предположить, что в десктопах используется systemd, то достаточно для каждого dm добавить *.service file. И как-то предусмотреть невозможность установки более одного dm.
А что ж им не пользоваться -- работает и достаточно предсказуемо. Кусочки в dm.d/ каком и впрямь напрашиваются, тем не менее.
(В ответ на комментарий №11) > Вообще вся эта архитектура prefdm устарела, конечно. Формат /etc/sysconfig/desktop тоже ;-)
(В ответ на комментарий №13) > для каждого dm добавить *.service file. Приведите пример строки my.service, в которой будет указан запуск до X-ов. > И как-то предусмотреть невозможность установки более одного dm. Боюсь, оно потянет за собой невозможность установки более одной de.
(В ответ на комментарий №16) > (В ответ на комментарий №13) > > для каждого dm добавить *.service file. > Приведите пример строки my.service, в которой будет указан запуск до X-ов. [Unit] Before=graphical.target [Install] WantedBy=graphical.target не понял, X где-то ещё запускаются? В чем проблема? Примеры для dm уже в апстримах: http://git.gnome.org/browse/gdm/tree/data/gdm.service.in > > И как-то предусмотреть невозможность установки более одного dm. > Боюсь, оно потянет за собой невозможность установки более одной de. Все dm умеют запускать разные de. Если dm провайдит виртуальный dm, а de требует не конкретный dm, а виртуальный - то все нормально.
(В ответ на комментарий №17) > [Unit] > Before=graphical.target > [Install] > WantedBy=graphical.target Спасибо! > В чем проблема? В недостаточном чтении докумментации :-)
(В ответ на комментарий №17) > > > И как-то предусмотреть невозможность установки более одного dm. > > Боюсь, оно потянет за собой невозможность установки более одной de. > Все dm умеют запускать разные de. > Если dm провайдит виртуальный dm, а de требует не конкретный dm >, а виртуальный - то все нормально. Если все будет хорошо, то все будет хорошо, но на самом деле хорошо не будет, поэтому хорошо не будет ;-) Лучше несколько *dm.service, чем бегать за мантейнерами других DE и просить, чтоб не гадили остальным.
(В ответ на комментарий №19) > (В ответ на комментарий №17) > > > > И как-то предусмотреть невозможность установки более одного dm. > > > Боюсь, оно потянет за собой невозможность установки более одной de. > > Все dm умеют запускать разные de. > > Если dm провайдит виртуальный dm, а de требует не конкретный dm > >, а виртуальный - то все нормально. > Если все будет хорошо, то все будет хорошо, но на самом деле хорошо не будет, > поэтому хорошо не будет ;-) > Лучше несколько *dm.service, чем бегать за мантейнерами других DE и просить, > чтоб не гадили остальным. Не спорю, несколько dm, не плохо. Только не будет одного места выбора. Надо делать: systemctl disable kdm.service systemctl enable gdm.service Или придумать какой-нибудь control, который это будет делать за пользователя.
(В ответ на комментарий №20) > Только не будет одного места выбора. А средствами systemd намудрить ничего нельзя? Там есть возможность запускать 1.service OR 2.service?
(В ответ на комментарий №21) > (В ответ на комментарий №20) > > Только не будет одного места выбора. > А средствами systemd намудрить ничего нельзя? > Там есть возможность запускать 1.service OR 2.service? Можно расставить конфликты, типа Conflicts=kdm.service Но тогда это будет рулетка, что запустится.
Или как вариант сделать файл prefdm.service альтернативой
(В ответ на комментарий №22) > Conflicts=kdm.service > Но тогда это будет рулетка, что запустится. Не. Это не подходит, кончено же.
(В ответ на комментарий №22) > Можно расставить конфликты, типа > Conflicts=kdm.service > Но тогда это будет рулетка, что запустится. Почему рулетка? запустится тот, который за-enable-ен. Если пользователь пытается запустить альтернативный, то первый будет остановлен. Если пользователь за-enable-ит более чем один, тогда, да, рулетка. Но рулетка с руганью, которая будет видна (явно). (В ответ на комментарий №11) > Вообще вся эта архитектура prefdm устарела, конечно. Тогда нужны альтернативы. Какие у нас есть альтернативы? service-файлы? пока я обнаружил оный только в одном gdm3.
gdm начиная с 3.28.2 таки перестанет пытаться игнорировать неизвестные опции и будет считать их ошибкой. https://bugzilla.gnome.org/show_bug.cgi?id=795494 https://git.gnome.org/browse/gdm/commit/?h=gnome-3-28&id=85a68ab14aad3d83abe1317d0c067f4d80a4dc82
Этот баг сильно устарел. При загрузке есть только display-manager.service, а каждый дистрибутив может при установке включать конкретный dm.service, который алиас на display-manager.service. Т.е. для systemd prefdm лишь одна из возможных альтернатив. В KWorkstation sddm.service включается при установке.
(В ответ на комментарий №20) > Надо делать: > systemctl disable kdm.service > systemctl enable gdm.service Я делаю: systemctl disable display-manager.service systemctl enable sddm.service systemctl enable sddm.service
(В ответ на комментарий №28) > systemctl enable sddm.service > systemctl enable sddm.service Нажал нечаянно. Вот то, что я делаю реально, переложенное на самый общий случай: systemctl disable display-manager.service systemctl enable realneed.service systemctl enable fallback1.service systemctl enable fallback2.service [...] systemctl enable prefdm.service systemctl enable display-manager.service
(В ответ на комментарий №29) > (В ответ на комментарий №28) > > systemctl enable sddm.service > > systemctl enable sddm.service > Нажал нечаянно. > Вот то, что я делаю реально, переложенное на самый общий случай: > systemctl disable display-manager.service > systemctl enable realneed.service > systemctl enable fallback1.service > systemctl enable fallback2.service > [...] > systemctl enable prefdm.service > systemctl enable display-manager.service Но зачем так много команд? Они все должны сами отрабатывать, при наличии /lib/systemd/system-preset/85-display-manager.preset и systemctl enable display-manager.service тоже не надо, лучше systemctl set-default graphical.target
Ну так что, не пришло время отказаться от prefdm? В предверии p9? Может оставить его только для sysv, а в systemd замаскировать (prefdm.service -> /dev/null)? Все *dm имеют unit файл для systemd.
(В ответ на комментарий №31) > Ну так что, не пришло время отказаться от prefdm? > В предверии p9? > Может оставить его только для sysv, а в systemd замаскировать (prefdm.service > -> /dev/null)? > Все *dm имеют unit файл для systemd. Хорошая мысль.
(В ответ на комментарий №31) > Ну так что, не пришло время отказаться от prefdm? Я в KWorkstation сразу отказался.
> Ну так что, не пришло время отказаться от prefdm? > В предверии p9? Это конечно хорошее решение, но что делать с обновлениями? Сегодня переводил одну из домашних машин с p8 на p9 -- эта система на ней ещё p6 видела, там systemd и вполне работал prefdm.service, запускавший lightdm. После перезагрузки prefdm.service запустить lightdm не смог и машина осталась без X: авг 01 08:53:17 europa.localdomain prefdm[1258]: Unknown option -nodaemon авг 01 08:53:17 europa.localdomain prefdm[1258]: Run 'lightdm --help' to see a full list of available command line options. Я то знаю что делать, но хотелось бы дистрибутивного решения.
*** Bug 36769 has been marked as a duplicate of this bug. ***
(В ответ на комментарий №34) > Это конечно хорошее решение, но что делать с обновлениями? триггер в .spec при обновлениия с версии меньше определенной(чтоб не портить более одного раза), который будет делать systemctl disable display-manager.service systemctl enable display-manager.service при отсутствии prefdm.service переключится любого присутствующего везунчика.
(В ответ на комментарий №36) > триггер в .spec при обновлениия с версии меньше определенной > (чтоб не портить более одного раза), который будет делать > systemctl disable display-manager.service > systemctl enable display-manager.service > при отсутствии prefdm.service переключится любого присутствующего везунчика. Н-да, на systemd-utils у нас уже зависимость в startup есть, оказывается.
(В ответ на комментарий №37) > Н-да, на systemd-utils у нас уже зависимость в startup есть, оказывается. Можно и без зависимости сделать. Не суть.
*** Bug 37182 has been marked as a duplicate of this bug. ***
До сих пор актуально. Я бы вообще убрал параметр -nodaemon из rundm и добавил в prefdm - там, где надо. Могу попробовать это изменение сделать.
Моя версия исправления: http://git.altlinux.org/people/slazav/packages/?p=xinitrc.git;a=commit;h=78f48d789a26b3374db09df03123eb60e38a36a4
*** Bug 39331 has been marked as a duplicate of this bug. ***
Это писец. 7 лет молоть языками и НИЧЕГО не сделать с багом, который вырубает возможность нормальной загрузки системы и гарантированно порождает сонм пользователей, которые всем расскажут "Какое падучее г. этот ваш линукс". Иметь готовое лекарство и не применить его... На своем примере убедился, что в Сизифе кошмар с dm без qt/kde зависимостей. gdm вообще не запускается непонятно почему, но может притянуться и выпихнуть gdm2.20 сломав загрузку (случалось). Lightdm тоже может сломаться при перестановках пакетов из-за этой гадкой опции...
(Ответ для Vyacheslav Dikonov на комментарий #43) > Это писец. > > 7 лет молоть языками и НИЧЕГО не сделать с багом, который вырубает > возможность нормальной загрузки системы и гарантированно порождает сонм > пользователей, которые всем расскажут "Какое падучее г. этот ваш линукс". > Иметь готовое лекарство и не применить его... > > На своем примере убедился, что в Сизифе кошмар с dm без qt/kde зависимостей. > gdm вообще не запускается непонятно почему, но может притянуться и выпихнуть > gdm2.20 сломав загрузку (случалось). Lightdm тоже может сломаться при > перестановках пакетов из-за этой гадкой опции... В стартеркитах, начная с p9, lightdm запускается через lightdm.service. Проблема существует только при обновлении стартеркитов с p8 на p9. Нужно выключить prefdm и включить lightdm.service
(Ответ для Антон Мидюков на комментарий #44) > Нужно Для любого дистрибутива # systemctl disable display-manager.service # systemctl enable нужныйDM.service
(Ответ для Антон Мидюков на комментарий #44) > В стартеркитах, начиная с p9, lightdm запускается через lightdm.service. > Проблема существует только при обновлении стартеркитов с p8 на p9. Не только стартеркитов -- дистрибутивов, видимо, тоже. > Нужно выключить prefdm и включить lightdm.service Кстати, жаль, что никто из наткнувшихся на это так и не добавил строчку на страничку http://altlinux.org/Update/p9; также просится в eepm, раз уж типовой рецепт. Добавил http://altlinux.org/Update/p9#Вход_в_систему_(prefdm)
(Ответ для Michael Shigorin на комментарий #46) > просится в eepm, раз уж типовой рецепт. Заскриптовать: # systemctl disable display-manager.service # systemctl enable sddm.service # systemctl enable lightdm.service # systemctl enable каждый-из-prefdm.service Первый попавшийся включится, остальные отработают вхолостую.
В этом пакете что-нибудь делать надо?
Ну вот чуть выше я писал свое предложение: http://git.altlinux.org/people/slazav/packages/?p=xinitrc.git;a=commit;h=78f48d789a26b3374db09df03123eb60e38a36a4 Насколько я помню, идея в том, чтобы из rundm.c и prefdm.service -dodaemon убрать. А prefdm пусть не только выбирает, какой dm нужен, но и подбирает нужные флаги для каждого dm. Так получится гораздо более гибкая схема, где каждый dm можно будет запускать с нужными флагами, не выделяя отдельно -nodaemon. Изменения в perfdm, возможно, надо еще внимательно кому-нибудь перечитать. Я там был в процессе починки своей неработающей системы и начал с того, что упростил все непонятное.
Я, честно говоря, не понимаю, зачем в современном мире нужен prefdm service, да ещё и такой, что знает про каждый dm настолько, что сам подбирает ему параметры.
Ну, тогда надо какое-то более глубокое изменение делать, убирать prefdm...
(Ответ для Dmitry V. Levin на комментарий #50) > Я, честно говоря, не понимаю, зачем в современном мире нужен prefdm service, Можно его убрать, а по окончанию # systemctl disable display-manager.service # systemctl enable display-manager.service и он включится, если какой-нибудь есть.
(Ответ для Dmitry V. Levin на комментарий #50) > Я, честно говоря, не понимаю, зачем в современном мире нужен prefdm service, > да ещё и такой, что знает про каждый dm настолько, что сам подбирает ему > параметры. К примеру, sddm через prefdm работает одинаково стабильно как в live, так и в установленной системе. А sddm.service не работает в live. И ещё одна проблема это sysvinit. Нужно же сделать init-скрипты для каждого display manager'а. Если сделать, то prefdm будет не нужен.
(Ответ для Антон Мидюков на комментарий #53) > К примеру, sddm через prefdm работает одинаково стабильно как в live, так и > в установленной системе. А sddm.service не работает в live. У меня работает. А вот, на aarch64 почему-то фиг. Я думал, причина связана с mkimage. Попробую выяснить. > И ещё одна проблема это sysvinit. Нужно же сделать init-скрипты для каждого > display manager'а. Если сделать, то prefdm будет не нужен. Для init можно оставить, если оно в systemd не пролезет, сконвертировавшись.
(Ответ для Sergey V Turchin на комментарий #54) > (Ответ для Антон Мидюков на комментарий #53) > > К примеру, sddm через prefdm работает одинаково стабильно как в live, так и > > в установленной системе. А sddm.service не работает в live. > У меня работает. В kworkstation 9.0 в live работает prefdm.service >А вот, на aarch64 почему-то фиг. Я думал, причина связана с > mkimage. Попробую выяснить. Мне кажется, там проблема с видеодрайвером. А включить программный рендеринг у меня не получилось. Потому я вообще отказался от sddm. > > > И ещё одна проблема это sysvinit. Нужно же сделать init-скрипты для каждого > > display manager'а. Если сделать, то prefdm будет не нужен. > Для init можно оставить, если оно в systemd не пролезет, сконвертировавшись. В sysvinit скоро не останется работающих display manager'ов. Так что делать нужно. Хотя бы к p10.
(Ответ для Антон Мидюков на комментарий #55) > В sysvinit скоро не останется работающих display manager'ов. wdm (и, подозреваю, xdm) всяко должны работать. Возможно, кому-то придётся по душе http://phab.enlightenment.org/w/projects/entrance/ (но aris@ смотрел и вроде как не пришлось).
(Ответ для Антон Мидюков на комментарий #55) > В kworkstation 9.0 в live работает prefdm.service Попробовал sddm в VB -- работает. Пойду патчить, чтоб не prefdm был.
> wdm (и, подозреваю, xdm) всяко должны работать. Я на xdm, он работает. Собственно, на проблему наткнулся, когда пытался играться с другими dm (мне хотелось чего-то странного, с доступом по vnc), но в результате все и так хорошо обустроил.
(Ответ для Sergey V Turchin на комментарий #57) > (Ответ для Антон Мидюков на комментарий #55) > > В kworkstation 9.0 в live работает prefdm.service > Попробовал sddm в VB -- работает. И он действительно работает. > Пойду патчить, чтоб не prefdm был. А при загрузке фигня. Если попереключаться на другую консоль. 12-ю, например, то всё стартует. Если не трогать -- блокируется. Как буд-то что-то с переключением терминала происходит или не происходит.
Мне кажется, что научить prefdm различать dm, которые он запускает - это правильный путь. Это исправление ошибок в той схеме, которая сейчас кое-как работает. Надо ли эту схему менять - это следующий вопрос, довольно нетривиальный (с учетом вопроса, кто будет поддерживать отдельные инит-скрипты для разных *dm).
(Ответ для Michael Shigorin на комментарий #46) > (Ответ для Антон Мидюков на комментарий #44) > > В стартеркитах, начиная с p9, lightdm запускается через lightdm.service. > > Проблема существует только при обновлении стартеркитов с p8 на p9. > Не только стартеркитов -- дистрибутивов, видимо, тоже. > > > Нужно выключить prefdm и включить lightdm.service > > Кстати, жаль, что никто из наткнувшихся на это так и не добавил строчку > на страничку http://altlinux.org/Update/p9; также просится в eepm, раз уж > типовой рецепт. > > Добавил http://altlinux.org/Update/p9#Вход_в_систему_(prefdm) Добавил в epm release-upgrade: + + # switch from prefdm: https://bugzilla.altlinux.org/show_bug.cgi?id=26405#c52 + if is_active_systemd systemd && serv display-manager status >/dev/null || serv prefdm status >/dev/null ; then + docmd systemctl disable prefdm.service + docmd systemctl disable display-manager.service + docmd systemctl enable display-manager.service + # docmd systemctl enable sddm.service + # docmd systemctl enable lightdm.service + fi + }
