Re: history EINTR bug

[Chet Ramey]

On 2/22/15 10:45 PM, gregrwm wrote:

>> >> > 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.

The two cases behave very differently.  In the `history' case, the shell
writes a line -- or history entry -- at a time using printf(3), since it
potentially has to write the associated timestamp for each one.  When it
writes to the history file, it assembles all of the history data into a
single buffer and writes it with a single write(2).  If that write fails,
the history library notes the error and attempts to restore the original
version of the history file.  It's true that there's no locking on the
history file and the possibility exists that multiple processes can write
to it at once.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/