On Fri, 15 Feb 2002 01:50, Borsenkow Andrej wrote:
> Debugging recent problem here I pbserved following:
>
> stracing devfsd for the first time using simple
>
> strace -p 69
>
> ends spitting out a screenfull of lines las one being output to stderr
> about broken pipe.
>
> Stracing the same devfsd the second time puts it into endless loop
> scanning /dev recursively and running REGISTER actions; if strace is
> killed immediately, devfsd calms down after 18s CPU time! (as reported
> by ps). I guess it is some bad interaction - devfsd does /dev rescan
> *every* time it receives an event from devfs and stracing process
> interrupts read.
>
> Is this rescan every time really necessary? Do I correctly understand it
> tries to compensate for missing events? But then it could check for
> overrun_count? Doing full rescan is very inefficient, at least here
> where we apply permissions every time.
When you attach to it the devfsd process will think that it has been sent a
SIGHUP and will reload it's config (which involves simulating events for all
active devices).
I think this is a bug, but haven't felt inclined to submit a patch as
stracing devfsd isn't something you often want to do and code bloat is
undesired.
Also while on this topic, don't run gdb on devfsd from within X. The X
server opens new devices if you try to change virtual consoles and often at
other times opens device files. If devfsd is blocked then the kernel will
block all open() calls for /dev, this can result in a system deadlock that
can only be killed by a SAK.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
|