[Lustre-discuss] clients gets EINTR from time to time

[Cory Spitz]

Hi.

I think it would help if you knew what the signal was.  Do you have that 
yet?

I have a report from a user that is is getting EINTR when a SIGALRM goes 
off on his write().  It isn't unexpected to get SIGALRM because he 
called the alarm, but he also has SA_RESTART set.  I can't remember 
whose responsibility it is to restart the call, syscall or whereever, 
but it seems that someone is dropping the ball because if EINTR is 
returned then SA_RESTART didn't seem to do the trick, right?

Thanks,
-Cory

On 2/25/2011 8:00 AM, Ken Hornstein wrote:
>> I don't understand why you don't just fix your application to handle a
>> perfectly valid and expected condition (that it's currently not
>> handling) instead of wasting time trying to find the cause of the
>> expected condition.  Even if you find it, it's likely not a bug and not
>> something that can/will be fixed.  It's your application that needs to
>> be fixed.
>
> To be fair ... normally disk I/O operations are not interruptable by
> signals, so it's not an unreasonable behavior on the part of an
> application.  I did check POSIX, and it doesn't say that behavior is
> restricted only to network sockets, so yeah, it's TECHNICALLY allowable
> behavior according to the standard (although the Linux manpage for
> signal(7) says that it will not happen).  But honestly, I've seen
> plenty of cases where applications handle this for network I/O; it's
> normal, everyone knows it will happen there.  But for _disk_ I/O?
> Never seen it done.  I'm not saying that there are no applications that
> handle this case, but it's certainly very uncommon.  I freely admit
> that network filesystems sort of mix the concepts of "network socket"
> and "disk I/O" together, and what is the "right" behavior is unclear.
> But calling this perfectly valid and expected is not quite accurate.
> It would be interesting to see what other network filesystems do under
> the same circumstances.
>
> --Ken
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-discuss