[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: history EINTR bug
From: |
gregrwm |
Subject: |
Re: history EINTR bug |
Date: |
Sun, 22 Feb 2015 21:45:20 -0600 |
On Feb 22, 2015 7:57 PM, "Chet Ramey" <chet.ramey@case.edu> wrote:
> On 2/22/15 5:57 PM, gregrwm wrote:
> > On Feb 13, 2015 7:38 AM, "Chet Ramey" <chet.ramey@case.edu
> > <mailto:chet.ramey@case.edu>> wrote:
> >> On 2/12/15 9:06 AM, gregrwm wrote:
> >> > i now suspect bash does not properly handle EINTR while handling history.
> >>
> >> Maybe. There's not enough information here to say.
> >>
> >> > this just happened:
> >> > bash: history: write error: Interrupted system call
> >>
> >> What command did you use?
> >
> > history|&less
>
> The most likely possibility is that you quit out of less before `history'
> wrote enough data to cause stdio to flush its output buffer and the SIGPIPE
> interrupted the write(2) when it did. I'm not sure why write would return
> -1/EINTR instead of -1/EPIPE, but behavior is not consistent across
> platforms.
since i'd never seen that error before, i left that less process up for days, musing over it until i had a moment to write you.
i'm thinking that when the system is rather busy, such for example as when numerous processes are all told to shutdown at once, EINTR occurs, and, in the case of the pipe, the history command never got the remainder of the history, but, in the case of writing out to the history file at shutdown, bash handles it by reattempting to write the history starting over again from the beginning of the history. that would explain the behavior captured in the bug report in the OP of this thread.