38229 2020-03-17 14:55:04 +0300 Невозможно сменить пользователя, если у пользователя настроен автоматический вход и пустой пароль 2020-03-31 18:29:20 +0300 1 1 4 Development Sisyphus plymouth unstable x86_64 Linux CLOSED FIXED P5 normal --- 33000 1 antohami antohami antohami manowar mike qa-sisyphus oldest_to_newest 188582 0 antohami 2020-03-17 14:55:04 +0300 Невозможно сменить пользователя, если у пользователя настроен автоматический вход и пустой пароль. Это актуально для live, где пользователь altlinux имеет пустой пароль и настроен автовход. Проявляется как у lightdm-gtk-greeter, так и у slick-greeter. 188583 1 manowar 2020-03-17 15:04:16 +0300 А что проявляется-то? Прошу по-порядку... 188584 2 antohami 2020-03-17 15:19:20 +0300 (Ответ для manowar@altlinux.org на комментарий #1) > А что проявляется-то? Прошу по-порядку... Загружаемся в live. Нажимаем завершить сеанс или сменить пользователя, сеанс завершается и тут же происходит автовход. Создаём ещё одного пользователя. Завершаем сеанс, происходит автовход в сеанс пользователя altlinux. Задаём пароль пользователю altlinux, и только тогда можно завершить сеанс и авторизоваться под другим пользователем. 188585 3 manowar 2020-03-17 15:29:57 +0300 Т.е. принудительное завершение сеанса не должно приводить к автоматическому воходу в систему? Вероятно вы правы. Вопрос в том, можно ли это как-то отследить... 188588 4 antohami 2020-03-17 15:51:41 +0300 (Ответ для manowar@altlinux.org на комментарий #3) > Т.е. принудительное завершение сеанса не должно приводить к автоматическому > воходу в систему? Вероятно вы правы. Вопрос в том, можно ли это как-то > отследить... В предыдущем релизе lightdm такой проблемы не было. Как понять принудительное? Самое обычное завершение сеанса пользователем, после которого не дожен происходить автоматический вход в этот сеанс. Во всяком случае без временной выдержки, которая должна включаться отдельно, опционально. 188607 5 antohami 2020-03-18 13:55:30 +0300 Дело не в lightdm. Висит в запущенном состоянии plymouth-start.service, чего быть не должно. Если его остановить, то выход из сессии происходит успешно. Перевешиваю на plymouth. Со вчерашнего дня пытаюсь понять странности с запуском lightdm, gdm, sddm. Похоже, после обновления systemd до 245 plymouth-start.service перестал завершаться после выполнения plymouth-quit.service Т.е. plymouth таки завершается, но начинается тут же заново. Наверное, теперь для systemd завершение программы (не аварийное) есть повод для запуска её вновь. И нужно как-то по-другому останавливать plymouth. Или в plymouth-start.service нужно что-то менять. Может сделать его: Type=oneshot ? 188610 6 shaba 2020-03-18 14:59:00 +0300 (Ответ для Антон Мидюков на комментарий #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 > ? 188611 7 shaba 2020-03-18 15:02:59 +0300 (Ответ для Антон Мидюков на комментарий #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 только для одноразовых скриптов. 188613 8 antohami 2020-03-18 16:38:13 +0300 (Ответ для 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 мс. 188772 9 antohami 2020-03-24 19:22:40 +0300 (Ответ для 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 Помогло. Как такой вариант? 188803 10 shaba 2020-03-25 20:03:56 +0300 (Ответ для Антон Мидюков на комментарий #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 188848 11 antohami 2020-03-26 19:03:35 +0300 (Ответ для 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 188907 12 antohami 2020-03-28 05:40:11 +0300 (Ответ для Антон Мидюков на комментарий #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 показывается снова и работает до своего завершения. Является ли это регрессом, напишу позже, не проверил. 188912 13 antohami 2020-03-28 14:17:16 +0300 (Ответ для Антон Мидюков на комментарий #12) > (Ответ для Антон Мидюков на комментарий #11) > > (Ответ для Alexey Shabalin на комментарий #10) > > > - добавить в plymouth-start.service ConditionPathExists=/etc/initrd-release, > > > тогда вне initrd он стартовать не должен. Но как к этому отнесутся другие > > > зависимые сервисы непонятно. > > > - заменить в plymouth-start.service ExecStart=/bin/true > > В обоих вариантах при использовании шифрованного раздела splash не > прерывается на ввод пароля. Приходится нажимать ESC, чтобы ввести пароль. > Затем, если нажать ESC, splash показывается снова и работает до своего > завершения. Является ли это регрессом, напишу позже, не проверил. Проверил, не регресс. 189013 14 repository-robot 2020-03-31 18:29:20 +0300 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)