Bug 38229

А что проявляется-то? Прошу по-порядку...

(Ответ для 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)