Jonas,
maybe the reason for your 3 minutes delay is that udevsettle has a builtin
timeout of 3 minutes.
That was my assumption.
Do you have any evidence?
er ... no ! Just the guesswork of the ignorant ;-)
It's just it hangs up every time for *exactly* 3 mins every time doing
something which normally completes within a second.
So that's my particular problem solved but obviously running udevsettle
from within a program is problematic.
can you elaborate on this?
Guessing again ... udevsettle waits until queued kernel/udev events are
handled. This seems to include waiting for "run programs" (programs
invoked by udev using the RUN= construct) to terminate. If a "run
program" invokes udevsettle then udevsettle will wait until itself
terminates - which is a deadlock.
This should be fairly easy to prove with a RUN=udevsettle in an
appropriate place. I just haven't done it yet.
in my eyes the reason to invoke udevsettle is to go sure that relevant
udev events have finished.
we need to know how long these events delay
in really bad situations to figure out a sane timout value for
udevsettle.
I have no idea how to determine this. It just seems to me that the
problem udevsettle was put into cryptsetup to resolve is mostly seen on
high-speed hardware so the delay needed is quite short. But I don't
really understand what's happening underneath all this so you're hearing
ignorance and guesswork speaking again.
if some situations cause the events to hang for i.e. 3 secs,
a timeout of 1 second would be to short.
That's always the problem with timeouts.
so as long as we don't know more about that, i would really like to
check first if udevsettle has a builtin timeout at all.
Yes. I think being alive to the potential for deadlock is more important.
maybe the 3 minutes delay is a problem on your side,
Obviously it's unacceptable. I do have a solution though.
My view now is that you shouldn't change cryptsetup. I think a note in
a README warning of this issue would be sufficient. The whole problem
will go away anyway once the underlying udev problem has been fixed.
I'll muck about run programs to try to prove my point and propose a
wording for documentation.
Dick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
