Systemd 241 Released With Security Fixes & Other Changes

[tildearrow]

@tildearrow

Sorry cannot quote on android for some reason. I think the problem is that 90s is for any service and while a user seasion might not need that long, other services might need that. I had the same problem with lxqt in the past but it was gone around lxqt 0.13 or so. Check that is actually blocking your session because that is the cause of the problem.

Note that the system is actually doing nothing during the 90 second wait, and systemd actually says "A stop job is running for Session of user [1 of 1]".

(you can quote on mobile by clicking the empty gap between the like button and the right margin and then selecting " Quote")

[pininety]

Note that the system is actually doing nothing during the 90 second wait, and systemd actually says "A stop job is running for Session of user [1 of 1]".

(you can quote on mobile by clicking the empty gap between the like button and the right margin and then selecting " Quote")

The system is waiting for a process in the user session to stop doing what it is doing, the problem is that there is most likely a process sitting there doing nothing for that 90 instead of just dying already. I think in my case it was menu-cache which just would not die on reboot and hence hang the reboot for 90s. That was the ticket at the time if I recall correctly:

https://github.com/lxqt/lxqt/issues/1311

If you are running an lxqt older than 0.13, you might want to try updating and see if it is fixed, if you are already on lxqt 0.13 or 0.14, there must be something else not getting the memo to finish up the work before it is hard killed by systemd after the 90s

PS:
Thanks for the tipp for android users. Would have nether found that without your help, thanks!

[re:fi.64]

Note that the system is actually doing nothing during the 90 second wait, and systemd actually says "A stop job is running for Session of user [1 of 1]".

(you can quote on mobile by clicking the empty gap between the like button and the right margin and then selecting " Quote")

To add to this a bit, run

journalctl -b-1 --user -e

to see the journal from the previous boot at the end, you should be able to see the log messages systemd writes when a process fails to die within the 90s timeout .

[oiaohm]

But from what I understand that only means the default configuration of a kernel shouldn't break userspace. If distro's or people want to ship a user-land console and apply the necessary kernel configuration to allow it for their builds, then surely that should be fine.

Problem is end up with two consoles as kmscon and linux kernel console is you end up with kmscon not always repeating kernel console messages. It also X11 and other things can at times talk to the Linux kernel console interfaces. Basically without redirecting the request going to the kernel console going to the usermode console you end up opening up a Pandora box of issues.

There are many issues that moving large blocks of the kernel mode console to userspace would be good. Designing the kernel mode console to be able to pass it requests to a usermode console interface will be good. Doing it the kmscon way shows the idea has merrit but it misses the userspace coner issues required so that if application attempt to talk to the kernel mode console directly by syscall that the user mode console responds correctly not being deaf as a post.