Ao fechar várias instâncias do bash ao mesmo tempo, há uma condição de corrida conhecida que pode fazer com que o histórico seja limpo. Isso ocorre porque não há bloqueio usado quando o arquivo de histórico do bash é gravado.
Chet Ramey (o atual mantenedor do bash) deu um bom resumo das condições para este problema:
The current (bash-4.3-devel) code works something like this, assuming no errors (lib/readline/histfile.c:history_do_write()):
- rename (histfile, histfile~)
- open file with O_CREAT|O_TRUNC
- malloc buffer large enough to hold all history data
- write all of the history entries in one write(2) call
- close file
- unlink (histfile~)
The bash-4.2 code works the same way except that it does not back up the history file. Each shell does the same thing when it exits, assuming histappend is not set, as in your configuration.
There are a couple of ways the history file can end up zero-length: the malloc can fail, or the write can fail. In bash-4.2, it's too late to do anything about the truncated history file at that point. In bash-4.3, the previous history file will be restored.
Este tópico da lista de discussão do bug-bash contém um decente discussão dos problemas, possíveis soluções e preocupações em torno disso.
Existem também outras possibilidades:
- Em algum momento, seu
HISTSIZE
ouHISTFILESIZE
foi definido como 0 - Em algum momento, sua readline
history-size
foi definida como 0 - Alguém, intencionalmente ou não, limpou o histórico bash (via
> "$HISTFILE"
ou similar)
No último caso, você pode querer verificar se alguém não acessou sua conta e está tentando ocultar seus rastros de uma forma crua. Dê uma olhada em last
, /var/log/auth
(ou /var/log/secure
no CentOS / RHEL) e, se tiver, qualquer software de contabilidade e / ou auditoria de processo que você tenha instalado.