View previous topic :: View next topic |
Author |
Message |
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Thu Sep 26, 2013 10:32 pm Post subject: [Solved] constant /etc/passwd access. [Solved] |
|
|
After trying to eliminate constant HDD activity while idle, (which I've already been mostly successful) I found that /etc/passwd was constantly being read & closed by a unknown prcoess (kernel?) using inotifywait.
/etc/ OPEN passwd
/etc/ CLOSE_NOWRITE,CLOSE passwd
/etc/ OPEN passwd
/etc/ CLOSE_NOWRITE,CLOSE passwd
/etc/ OPEN passwd
at least once or more per second.
I tried using lsof & fuser with watch to find out the process accessing it but it returned nothing at all.
Could someone explain what might be going on? And if its really necessary to check passwd file that many times per second.
Thanks in advance.
Last edited by zeronullity on Mon Sep 30, 2013 8:44 pm; edited 2 times in total |
|
Back to top |
|
|
PaulBredbury Watchman
Joined: 14 Jul 2005 Posts: 7310
|
Posted: Thu Sep 26, 2013 11:15 pm Post subject: |
|
|
Use iotop to find the misbehaving process. |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Fri Sep 27, 2013 12:51 am Post subject: |
|
|
After recompiling the kernel with the correct options.. The only thing iotop shows is a kworker thread that is active..
so this still really doesn't address my original question of why the passwd file is being accessed so much. It appears that
its a kworker thread accessing the file but why so much? |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Fri Sep 27, 2013 7:49 am Post subject: |
|
|
I guess I'll have to get more information from the kernel worker threads once I recall which kernel options I need to enable to use them..
echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
cat /sys/kernel/debug/tracing/trace_pipe > out
some thing debugging &/or tracing in the kernel config I assume.
Just hoping someone had a similar issue and knew a common answer.. I didn't want to have to go into kernel debugging mode, as I suspected I might.. =) |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Fri Sep 27, 2013 9:50 am Post subject: |
|
|
So after taking a look in Kernel Shark.. it seemed the issue was coming from X and possibly kwin.. after stopping xdm / X / KDE the problem stopped.. after starting just X the problem still didn't occur..
so it has something to do with the kwin / KDE and/or one of it's startup processes.. but I'm stumped as to what it could be or the next step. |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Fri Sep 27, 2013 9:58 am Post subject: |
|
|
So after taking a look in Kernel Shark.. it seemed the issue was coming from X and possibly kwin.. after stopping xdm / X / KDE the problem stopped.. after starting just X the problem still didn't occur..
so it has something to do with the kwin / KDE and/or one of it's startup processes.. but I'm stumped as to what it could be or the next step. |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Fri Sep 27, 2013 3:53 pm Post subject: |
|
|
Not that I know something about it. But, if kde is involved, and it's looking into the password file, then it could be related to the kde wallet, or whatever controls the passwords ring in kde nowadays. I don't even remember... That, or kdm/*kit doing its stuff. |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Fri Sep 27, 2013 5:10 pm Post subject: |
|
|
I was wrong it still occurs with Xorg stopped just not as often. I also noticed init [3] at the top of PS so I did a strace on pid 1
stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
select(11, [10], NULL, NULL, {5, 0}) = 0 (Timeout)
stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
select(11, [10], NULL, NULL, {5, 0}) = 0 (Timeout)
stat("/dev/initctl", {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
ls -al /dev/initctl
lprw------- 1 root root 0 Sep 27 10:56 /dev/initctl
Still at a loss of whats going on however or why it appears to occur more often with KDE started. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Fri Sep 27, 2013 5:42 pm Post subject: |
|
|
Unless you're running nscd, every uid to username lookup has to go through that file. |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Fri Sep 27, 2013 10:02 pm Post subject: |
|
|
Further digging with strace & htop..
Problem does not occur at login screen only after user has logged in and kwin is loaded.
Using htop I killed all processes[kwalletd,akonadi,plasma desktop, kmail,polkit,consolekit,irqbalance etc. etc.] leaving just kwin, ksmserver, klauncher, X. problem still occurs and the only cpu activity is from X & Kwin.
Killing kwin, ksmserver or klaunch, boots me back to the login screen.. and the problem stops..
So the problem appears to be with kwin any further ideas? |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Sun Sep 29, 2013 5:00 am Post subject: |
|
|
Update..
I've traced the loop back to konsole executed by kdeinit4 so long as a konsole window is open this loop will occur non-stop.. I've checked all the settings..
Not sure any reason it should be running in a non-stop loop?
This does not occur in other terminals such as xterm for X. |
|
Back to top |
|
|
boerKrelis Apprentice
Joined: 01 Jul 2003 Posts: 241 Location: The Netherlands
|
Posted: Sun Sep 29, 2013 9:08 am Post subject: |
|
|
I expect the reads of /etc/passwd to be served from the file cache.
So while it's interesting to find out what is reading it, the reading itself does not necessarily translate to disk activity, which is your main concern... |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Sun Sep 29, 2013 10:54 am Post subject: |
|
|
boerKrelis wrote: | I expect the reads of /etc/passwd to be served from the file cache.
So while it's interesting to find out what is reading it, the reading itself does not necessarily translate to disk activity, which is your main concern... |
Yeh, my disk activity is currently under control.. this question was only addressing the constant loop.. which I found during that particular concern.
Now its just a security / bug / configuration concern.. since it appears to be looping. I assume no one else is having the same activity while using Konsole?
I also used other emulators like guake,xterm,uxterm and no issues there either. So my temp fix atm is to use another emulator until I can trace it to the exact
cause within konsole.. unless any one else comes up with any other ideas or solutions, as I can think of no good reason it should be reading that file cached or not
that many times per second. |
|
Back to top |
|
|
Aiken Apprentice
Joined: 22 Jan 2003 Posts: 239 Location: Toowoomba/Australia
|
Posted: Sun Sep 29, 2013 6:49 pm Post subject: |
|
|
Using strace -p on a running konsole shows it is regularly reading /etc/passwd /proc/<child>/stat /proc/<child>/cmdline /proc/<child>/cwd/
Where <child> seems to be the current running process. When idle that is bash. It changes the window title based on what is running and I am assuming it is using the values found in these files and directory to get this info.
Never noticed this before. The only time I use konsole is if I don't have my preferred terminal emulator installed yet. _________________ Beware the grue. |
|
Back to top |
|
|
zeronullity Tux's lil' helper
Joined: 16 Oct 2010 Posts: 103
|
Posted: Sun Sep 29, 2013 8:12 pm Post subject: |
|
|
Aiken wrote: | Using strace -p on a running konsole shows it is regularly reading /etc/passwd /proc/<child>/stat /proc/<child>/cmdline /proc/<child>/cwd/
Where <child> seems to be the current running process. When idle that is bash. It changes the window title based on what is running and I am assuming it is using the values found in these files and directory to get this info.
Never noticed this before. The only time I use konsole is if I don't have my preferred terminal emulator installed yet. |
I agree seems to have something to do with title window updates, I'm moving this to solved and taking it up with KDE developers. - Thanks
UPDATE:
Bug submitted & confirmed
Bug 325442 - KDE bug-tracking system. |
|
Back to top |
|
|
|