https://bugs.kde.org/show_bug.cgi?id=402540
Bug ID: 402540
Summary: Login VERY slow due to cleanup_fds
Product: frameworks-kinit
Version: 5.51.0
Platform: Debian unstable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: fa...@kde.org
Reporter: k...@reimardoeffinger.de
CC: kdelibs-b...@kde.org
Target Milestone: ---
SUMMARY
Logging in takes over 1 minute, with kdeinit5 using 100% CPU.
This happens if the HARD limit on number of file descriptors is set to a very
high value (> 1 million on my machine - I am not aware of ever changing that,
so it must somehow be the default).
STEPS TO REPRODUCE
1. Ensure ulimit -n -H is set to millions for some user account
2. log in with that user in SDDM
OBSERVED RESULT
Login takes at least 1 minute or more, depending on the ulimit value
EXPECTED RESULT
Login should be immediate.
SOFTWARE/OS VERSIONS
KDE Frameworks Version: 5.51.0-1 (Debian unstable)
ADDITIONAL INFORMATION
The problematic code is in kinit.cpp:
static void cleanup_fds()
{
int maxfd = FD_SETSIZE;
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) == 0) {
maxfd = rl.rlim_max;
}
for (int fd = 3; fd < maxfd; ++fd) {
#if KDEINIT_OOM_PROTECT
if (fd != oom_pipe)
#endif
close(fd);
}
}
I believe a good first step would be to check if rlimit_cur could safely be
used instead of rlimit_max.
If not, it would be a good idea to either
1) ensure kdeinit5 does not block the whole login process
2) SDDM either sets this limit to a reasonable value itself, or at least warns
the user about it, so that a somewhat "normal" user has a chance to fix it
without having to break out GDB to figure out where the hang comes from
3) Do this in a more clever way, e.g. check /proc/self/fd (maybe there is even
a programmatic interface?) for which fds are even in use. There probably are
programs that have implemented this in a better way?
Note that the spectre/meltdown fixes probably made this issue FAR more
noticeable.
--
You are receiving this mail because:
You are watching all bug changes.
