Skip to main content ↑ ↓
Topic: Vanishing history  (Read 1562 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Vanishing history

.bashrc :
HISTSIZE=10000
HISTFILESIZE=20000

$ man bash
HISTFILE
              The  name of the file in which command history is saved (see HISTORY below).  The default value is ~/.bash_history.  If unset, the command history is not saved
              when a shell exits.
       HISTFILESIZE
              The maximum number of lines contained in the history file.  When this variable is assigned a value, the history file is truncated, if necessary, to contain  no
              more  than  that  number of lines by removing the oldest entries.  The history file is also truncated to this size after writing it when a shell exits.  If the
              value is 0, the history file is truncated to zero size.  Non-numeric values and numeric values less than zero inhibit truncation.  The shell sets  the  default
              value to the value of HISTSIZE after reading any startup files.

But now my .bash_history only has the last month or so of history in it, only 871 lines at present. A lot of earlier stuff has just gone, I'll have to get it back from an rsynced backup now.

Re: Vanishing history

Reply #1 –
Are those vars exported?

Code: [Select]
% set | grep HIST
HISTCONTROL=erasedups:ignoreboth
HISTFILE=/home/nous/.bash_history
HISTFILESIZE=10000000
HISTSIZE=1000000
 

Re: Vanishing history

Reply #2 –
It seems to look OK, and has been working otherwise. I don't see any command near the top of the new short bash_history file that would account for this, if it had been mistakenly deleted then that command would be saved when the terminal that issued it was closed, and I almost always do file operations on the command line, apart from deleting photos in a viewer, and my Thunar isn't set to show hidden files, so it's very unlikely (although nothing is impossible) to be a fat finger incident. I ran a btrfs scrub recently which came back clean, the only other possibility I can think of is if a terminal got left open at shutdown (and things like that do happen here on rare occasions... :D )  and something went wrong because of that.
Code: [Select]
$ set |grep HIST
HISTFILE=/home/me/.bash_history
HISTFILESIZE=20000
HISTSIZE=10000
$ set |grep hist
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:progcomp:promptvars:sourcepath
HISTFILE=/home/me/.bash_history
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
$ shopt -p |grep hist
shopt -s cmdhist
shopt -s histappend
shopt -u histreedit
shopt -u histverify
shopt -u lithist

Re: Vanishing history

Reply #3 –
Quote from: ####### – on
the only other possibility I can think of is if a terminal got left open at shutdown (and things like that do happen here on rare occasions... :D )  and something went wrong because of that.
I've lost thousands of history lines because of unclean shutdowns (or video card freezes...) and subsequent bootup fsck. Have you checked in /lost+found?

Re: Vanishing history

Reply #4 –
updatedb - locate bash_history turns up nothing, and there is no lost+found. With BTRFS all that usually happens is you might get a checksum error when you do a scrub, the file stays where it is. For example, recently with a BTRFS USB:
$ sudo btrfs scrub status /mnt
scrub status for 71cf0768-d6d6-4dcf-9628-cd645ca7a66d
        scrub started at Sun Sep 16 14:56:58 2018 and finished after 00:02:22
        total bytes scrubbed: 2.72GiB with 6 errors
        error details: csum=6
        corrected errors: 0, uncorrectable errors: 6, unverified errors: 0
(change tail to number of errors, and you can see which files need deleting / replacing / copying for further attention)
$ dmesg | grep "checksum error at" | tail -6 | cut -d\  -f24- | sed 's/.$//'
So you don't get fsck'ed at boot, and even with EXT4 I had to run the fsck manually to delete affected files.  I had another OS on BTRFS on another PC which had a checksum error for months and it kept working, until I figured out how to find the file, delete it and run another scrub. In rare difficult cases you can get undeletable files though, and more involved things are needed.