purevw:
The only pre-timeout failure is the package “pidgin” and it is always the same:
3145.197645] systemd[1]: Received SIGCHLD from PID 3606 (pidgin).
3145.197658] systemd[1]: Child 3606 (pidgin) died (code=exited, status=1/FAILURE)
3145.197688] systemd[1]: session-2.scope: Failed to read oom_kill field of memory.events cgroup attribute: No such file or directory
3145.197690] systemd[1]: session-2.scope: Child 3606 belongs to session-2.scope.
The code shows that the process died, so I am not sure of it could be causing the timeout. I also do not know why pidgin is under Session-2, unless pidgin is spawning Session-2 if I open an active chat window.
I will verify the theory shortly. I do not run pidgin as SU, but I do have it set to autostart with KDE upon login.
I have saved 3 of the shutdown.txt files and they all show the same at the end of the time-out. It is basically the same information as the journalctl command gave me:
From failure 1:
3235.494506] systemd[1]: session-2.scope: Stopping timed out. Killing.
3235.494779] systemd[1]: session-2.scope: Killing process 3937 (kdesud) with signal SIGKILL.
3235.494831] systemd[1]: session-2.scope: Failed with result 'timeout'.
3235.494838] systemd[1]: session-2.scope changed stop-sigterm -> failed
From failure 2:
1871.515893] systemd[1]: session-2.scope: Stopping timed out. Killing.
1871.516037] systemd[1]: session-2.scope: Killing process 3833 (kdesud) with signal SIGKILL.
1871.516094] systemd[1]: session-2.scope: Failed with result 'timeout'.
1871.516103] systemd[1]: session-2.scope changed stop-sigterm -> failed
From failure 3:
6451.547019] systemd[1]: systemd-timesyncd.service: Got notification message from PID 1364 (WATCHDOG=1)
6472.546754] systemd[1]: session-2.scope: Stopping timed out. Killing.
6472.546901] systemd[1]: session-2.scope: Killing process 2894 (kdesud) with signal SIGKILL.
6472.546961] systemd[1]: session-2.scope: Failed with result 'timeout'.
6472.546969] systemd[1]: session-2.scope changed stop-sigterm -> failed
It seems that kdesud may be a problem. My question is, what is causing Session-2 of my user to start in the first place? On the third failure, the only package I ran as root was Yast2.Online Update. It was opened by the system icon and not by a terminal. That is the only time I used the admin password during that session.
On my machine there is a unit session-2.scope too:
**erlangen:~ #** systemctl list-units --type scope
UNIT LOAD ACTIVE SUB DESCRIPTION
init.scope loaded active running System and Service Manager
session-2.scope loaded active running Session 2 of user karl
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
**2 loaded units listed.** Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
**erlangen:~ #**
In the first place it’s me who is creating this unit by logging in.