http://bugzilla.opensuse.org/show_bug.cgi?id=1207367 Bug ID: 1207367 Summary: kwalletd5 takes a long time to start if fs.nr_open and the default nofiles limit is large Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Minor Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs@opensuse.org Reporter: gcj9exvx-opensuse@yahoo.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 864298 --> http://bugzilla.opensuse.org/attachment.cgi?id=864298&action=edit Screenshot of systemmonitor and partial output of pstree showing busy kdeinit5 process To reproduce: - Use a standard Tumbleweed KDE setup with sddm login, KDE Wallet enabled and a wallet set up and automatically loaded on startup. - Set fs.nr_open to a somewhat large number than the default 1048576 like 1024*1024*128 (134217728). On very fast systems, go larger to get more time to observe. - Increase the default open files limit to the value of fs.nr_open. Setting it to unlimited will by default result in nofile getting set to equal fs.nr_open, so adding a file 99-nofile.conf to /etc/security/limits.d/99-nofile.conf with the contents ------------------- snip ----------------------------------------------- * soft nofile unlimited * hard nofile unlimited ------------------- snip ----------------------------------------------- will work. - Log out of KDE session and relogin through sddm - Observe a kdeinit5 process with high CPU activity. kwallet access is blocked while this process running, potentially blocking applications trying to access kwallet during this time (such as certain popular webbrowsers). Ref. attached screenshot for example. - Attach strace to pid of the kdeinit5 process mentioned above. Sample output right before the kdeinit5 process finally terminates after a couple of minutes. It looks like the process is somehow iterating over every single file descriptor available and only terminates afterwards. ------------------- snip ----------------------------------------------- close(134217696) = -1 EBADF (Bad file descriptor) close(134217697) = -1 EBADF (Bad file descriptor) close(134217698) = -1 EBADF (Bad file descriptor) close(134217699) = -1 EBADF (Bad file descriptor) close(134217700) = -1 EBADF (Bad file descriptor) close(134217701) = -1 EBADF (Bad file descriptor) close(134217702) = -1 EBADF (Bad file descriptor) close(134217703) = -1 EBADF (Bad file descriptor) close(134217704) = -1 EBADF (Bad file descriptor) close(134217705) = -1 EBADF (Bad file descriptor) close(134217706) = -1 EBADF (Bad file descriptor) close(134217707) = -1 EBADF (Bad file descriptor) close(134217708) = -1 EBADF (Bad file descriptor) close(134217709) = -1 EBADF (Bad file descriptor) close(134217710) = -1 EBADF (Bad file descriptor) close(134217711) = -1 EBADF (Bad file descriptor) close(134217712) = -1 EBADF (Bad file descriptor) close(134217713) = -1 EBADF (Bad file descriptor) close(134217714) = -1 EBADF (Bad file descriptor) close(134217715) = -1 EBADF (Bad file descriptor) close(134217716) = -1 EBADF (Bad file descriptor) close(134217717) = -1 EBADF (Bad file descriptor) close(134217718) = -1 EBADF (Bad file descriptor) close(134217719) = -1 EBADF (Bad file descriptor) close(134217720) = -1 EBADF (Bad file descriptor) close(134217721) = -1 EBADF (Bad file descriptor) close(134217722) = -1 EBADF (Bad file descriptor) close(134217723) = -1 EBADF (Bad file descriptor) close(134217724) = -1 EBADF (Bad file descriptor) close(134217725) = -1 EBADF (Bad file descriptor) close(134217726) = -1 EBADF (Bad file descriptor) close(134217727) = -1 EBADF (Bad file descriptor) dup2(2, 1) = 1 pipe2([3, 4], 0) = 0 rt_sigaction(SIGCHLD, {sa_handler=0x565343311560, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f38e82428e0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f38e89c8890) = 27299 close(4) = 0 read(3, "\0", 1) = 1 close(3) = 0 futex(0x7f38e89bd288, FUTEX_WAKE_PRIVATE, 2147483647) = 0 getpid() = 26212 exit_group(0) = ? +++ exited with 0 +++ ------------------- snip ----------------------------------------------- - Other interesting observations: User account that the kdeinit5 process is running under does NOT have raised nofile limits: ------------------- snip ----------------------------------------------- michael@beast:~> ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 30 file size (blocks, -f) unlimited pending signals (-i) 126667 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 95 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 126667 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ------------------- snip ----------------------------------------------- Only root does: ------------------- snip ----------------------------------------------- beast:~ # ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 126667 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 134217728 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 126667 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ------------------- snip ----------------------------------------------- -- You are receiving this mail because: You are on the CC list for the bug.