Невозможно сменить пользователя, если у пользователя настроен автоматический вход и пустой пароль. Это актуально для live, где пользователь altlinux имеет пустой пароль и настроен автовход. Проявляется как у lightdm-gtk-greeter, так и у slick-greeter.
А что проявляется-то? Прошу по-порядку...
(Ответ для manowar@altlinux.org на комментарий #1) > А что проявляется-то? Прошу по-порядку... Загружаемся в live. Нажимаем завершить сеанс или сменить пользователя, сеанс завершается и тут же происходит автовход. Создаём ещё одного пользователя. Завершаем сеанс, происходит автовход в сеанс пользователя altlinux. Задаём пароль пользователю altlinux, и только тогда можно завершить сеанс и авторизоваться под другим пользователем.
Т.е. принудительное завершение сеанса не должно приводить к автоматическому воходу в систему? Вероятно вы правы. Вопрос в том, можно ли это как-то отследить...
(Ответ для manowar@altlinux.org на комментарий #3) > Т.е. принудительное завершение сеанса не должно приводить к автоматическому > воходу в систему? Вероятно вы правы. Вопрос в том, можно ли это как-то > отследить... В предыдущем релизе lightdm такой проблемы не было. Как понять принудительное? Самое обычное завершение сеанса пользователем, после которого не дожен происходить автоматический вход в этот сеанс. Во всяком случае без временной выдержки, которая должна включаться отдельно, опционально.
Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего быть не должно. Если его остановить, то выход из сессии происходит успешно. Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245 plymouth-start.service перестал завершаться после выполнения plymouth-quit.service Т.е. plymouth таки завершается, но начинается тут же заново. Наверное, теперь для systemd завершение программы (не аварийное) есть повод для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или в plymouth-start.service нужно что-то менять. Может сделать его: Type=oneshot ?
(Ответ для Антон Мидюков на комментарий #5) > Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего > быть не должно. Если его остановить, то выход из сессии происходит успешно. > > Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с > запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245 > plymouth-start.service перестал завершаться после выполнения > plymouth-quit.service > Т.е. plymouth таки завершается, но начинается тут же заново. > Наверное, теперь для systemd завершение программы (не аварийное) есть повод > для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или > в plymouth-start.service нужно что-то менять. Может сделать его: > Type=oneshot > ?
(Ответ для Антон Мидюков на комментарий #5) > Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего > быть не должно. Если его остановить, то выход из сессии происходит успешно. У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не должен стартовать. Должен только plymouth-quit.service отработать. plymouth-start.service - это сервис для initrd, если бы в initrd был systemd. > > Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с > запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245 > plymouth-start.service перестал завершаться после выполнения > plymouth-quit.service > Т.е. plymouth таки завершается, но начинается тут же заново. > Наверное, теперь для systemd завершение программы (не аварийное) есть повод > для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или > в plymouth-start.service нужно что-то менять. Может сделать его: > Type=oneshot > ? oneshot нельзя, потому что там демон остается работать. oneshot только для одноразовых скриптов.
(Ответ для Alexey Shabalin на комментарий #7) > oneshot нельзя, потому что там демон остается работать. oneshot только для > одноразовых скриптов. Его plymouth-quit.service завершает в таком случае. >У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не >должен стартовать. Должен только plymouth-quit.service отработать. >plymouth-start.service - это сервис для initrd, если бы в initrd был systemd. Посмотрел сборку от 27.02.2020. Запускался таки plymouth-start.service, на 15 мс.
(Ответ для Alexey Shabalin на комментарий #7) > (Ответ для Антон Мидюков на комментарий #5) > > Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего > > быть не должно. Если его остановить, то выход из сессии происходит успешно. > > У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не > должен стартовать. Должен только plymouth-quit.service отработать. > plymouth-start.service - это сервис для initrd, если бы в initrd был systemd. Я удалил plymouth-start.service со всеми ссылками на него, собралось: [#248433] TESTED plymouth.git=0.9.4-alt3 Помогло. Как такой вариант?
(Ответ для Антон Мидюков на комментарий #9) > (Ответ для Alexey Shabalin на комментарий #7) > > (Ответ для Антон Мидюков на комментарий #5) > > > Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего > > > быть не должно. Если его остановить, то выход из сессии происходит успешно. > > > > У нас plymouth стартует из initrd, поэтому plymouth-start.service вообще не > > должен стартовать. Должен только plymouth-quit.service отработать. > > plymouth-start.service - это сервис для initrd, если бы в initrd был systemd. > > > Я удалил plymouth-start.service со всеми ссылками на него, собралось: > [#248433] TESTED plymouth.git=0.9.4-alt3 > > Помогло. Как такой вариант? Мне не очень нравится такое решение. на plymouth-start.service есть зависимости не только в пакете plymouth, но и в systemd, gdm. Надо попробовать 3 таких варианта: - просто замаскировать systemctl mask plymouth-start.service - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release, тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие зависимые сервисы непонятно. - заменить в plymouth-start.service ExecStart=/bin/true
(Ответ для Alexey Shabalin на комментарий #10) > > Мне не очень нравится такое решение. > на plymouth-start.service есть зависимости не только в пакете plymouth, но и > в systemd, gdm. А почему сборочница это пропустила? > > Надо попробовать 3 таких варианта: > - просто замаскировать systemctl mask plymouth-start.service Этот вариант проверил. Работает. Проблем не заметил. Может на этом варианте и остановимся? > - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release, > тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие > зависимые сервисы непонятно. > - заменить в plymouth-start.service ExecStart=/bin/true
(Ответ для Антон Мидюков на комментарий #11) > (Ответ для Alexey Shabalin на комментарий #10) > > > > Мне не очень нравится такое решение. > > на plymouth-start.service есть зависимости не только в пакете plymouth, но и > > в systemd, gdm. > > А почему сборочница это пропустила? > > > > > Надо попробовать 3 таких варианта: > > - просто замаскировать systemctl mask plymouth-start.service > > Этот вариант проверил. Работает. Проблем не заметил. Может на этом варианте > и остановимся? При использовании шифрованного раздела не получается загрузиться: https://lists.altlinux.org/pipermail/sisyphus/2020-March/368499.html Ситуацию воспроизвёл. Так что не подходит этот вариант. splash не получается прервать, запускается снова. > > - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release, > > тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие > > зависимые сервисы непонятно. > > - заменить в plymouth-start.service ExecStart=/bin/true В обоих вариантах при использовании шифрованного раздела splash не прерывается на ввод пароля. Приходится нажимать ESC, чтобы ввести пароль. Затем, если нажать ESC, splash показывается снова и работает до своего завершения. Является ли это регрессом, напишу позже, не проверил.
(Ответ для Антон Мидюков на комментарий #12) > (Ответ для Антон Мидюков на комментарий #11) > > (Ответ для Alexey Shabalin на комментарий #10) > > > - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release, > > > тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие > > > зависимые сервисы непонятно. > > > - заменить в plymouth-start.service ExecStart=/bin/true > > В обоих вариантах при использовании шифрованного раздела splash не > прерывается на ввод пароля. Приходится нажимать ESC, чтобы ввести пароль. > Затем, если нажать ESC, splash показывается снова и работает до своего > завершения. Является ли это регрессом, напишу позже, не проверил. Проверил, не регресс.
plymouth-1:0.9.4-alt3 -> sisyphus: Tue Mar 31 2020 Anton Midyukov <antohami@altlinux> 1:0.9.4-alt3 - plymouth-start.service: ExecStart=/bin/true (Closes: 38229)
