Bug#925160: systemd: user session slow to start (11 seconds)

Laurent Bonnaud L.Bonnaud at laposte.net
Thu Mar 21 12:51:32 GMT 2019


On 20/03/2019 19.39, Michael Biebl wrote:

> Another info that might help give a clue is setting
> LogLevel=debug in /etc/systemd/user.conf, reboot, log in, then attach
> the output of journalctl --user -b

Thanks, it allowed me to find the cause of the problem:

Mar 21 13:41:49 hostname sshd[237915]: Accepted publickey for root from 193.55.51.152 port 41646 ssh2: RSA SHA256:wmFQ70BsRjT4uCWua2ddnbfFv7kiMecLHVNtZMw0KMk
Mar 21 13:41:49 hostname sshd[237915]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 21 13:41:49 hostname systemd-logind[743]: New session 4844 of user root.
Mar 21 13:41:49 hostname systemd[1]: Starting User Manager for UID 0...
Mar 21 13:41:49 hostname systemd[237918]: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Mar 21 13:41:49 hostname systemd[237918]: Found container virtualization none.
Mar 21 13:41:49 hostname systemd[237918]: systemd 241 running in user mode for user 0/root. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELF
Mar 21 13:41:49 hostname systemd[237918]: RLIMIT_MEMLOCK is already as high or higher than we need it, not bumping.
Mar 21 13:41:49 hostname systemd[237918]: Found cgroup2 on /sys/fs/cgroup/unified, unified hierarchy for systemd controller
Mar 21 13:41:49 hostname systemd[237918]: Unified cgroup hierarchy is located at /sys/fs/cgroup/unified/user.slice/user-0.slice/user at 0.service. Controllers are on legacy hierarchies.
Mar 21 13:41:49 hostname systemd[237918]: Got EBADF when using BPF_F_ALLOW_MULTI, which indicates it is supported. Yay!
Mar 21 13:41:49 hostname systemd[237918]: Controller 'cpu' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'cpuacct' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'io' supported: no
Mar 21 13:41:49 hostname systemd[237918]: Controller 'blkio' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'memory' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'devices' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'pids' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'bpf-firewall' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Controller 'bpf-devices' supported: yes
Mar 21 13:41:49 hostname systemd[237918]: Set up TFD_TIMER_CANCEL_ON_SET timerfd.
Mar 21 13:41:49 hostname systemd[237918]: Serializing user-environment-generators to memfd.
Mar 21 13:41:49 hostname systemd[237918]: Successfully forked off '(sd-executor)' as PID 237922.
Mar 21 13:41:49 hostname systemd[237922]: Serializing 30-systemd-environment-d-generator to memfd.
Mar 21 13:41:49 hostname systemd[237922]: Successfully forked off '(direxec)' as PID 237923.
Mar 21 13:41:49 hostname systemd[237922]: /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator succeeded.
Mar 21 13:41:49 hostname systemd[237922]: Serializing 60-flatpak to memfd.
Mar 21 13:41:49 hostname systemd[237922]: Successfully forked off '(direxec)' as PID 237924.
Mar 21 13:41:49 hostname systemd[237922]: /usr/lib/systemd/user-environment-generators/60-flatpak succeeded.
Mar 21 13:41:49 hostname systemd[237922]: Serializing 70-im-config to memfd.
Mar 21 13:41:49 hostname systemd[237922]: Successfully forked off '(direxec)' as PID 237927.
Mar 21 13:42:02 hostname systemd[237922]: /usr/lib/systemd/user-environment-generators/70-im-config succeeded.

Therefore the problem is in /usr/lib/systemd/user-environment-generators/70-im-config.  Moving this file away solves the problem :>.

Should I reassign this bug to the im-config package ?

Thanks again,

-- 
Laurent.



More information about the Pkg-systemd-maintainers mailing list