[SOLVED] How to find out the Time Stamp of the history?

thomas2004ch · 08-28-2014, 04:42 AM

As I run command 'history' I got a long list of command history with the command number. But how can I find out the Time Stamp, i.e., at what time a command is executed?

cliffordw · 08-28-2014, 04:54 AM

Hi,

Try setting the HISTTIMEFORMAT environment variable first, as follows:

Code:

HISTTIMEFORMAT="%Y-%m-%d %T "
history

It's probably a good idea to put this in your ~/.bashrc file too.

Regards,

Clifford

thomas2004ch · 08-28-2014, 05:49 AM

Hi,

Sorry. I thought your answer is correct. But as I look the history deeply I found all the command in the history list have the same Time Stamp. For example, I have many commands yesterday. But as call the history now, I see all the command from yesterday or earlier have the same Time Stamp from today.

This is not what I want.

cliffordw · 08-28-2014, 07:28 AM

Hi again,

I saw the same thing earlier this week on a different machine, but then got correct timestamps when I tried it on my own machine this morning. Sorry, I should have mentioned that.

I think the variable needs to be set in order for the timestamp data to be collected/saved. That means what you're seeing is entries that weren't saved with a timestamp, and there is no way to see timestamps for such entries.

Setting it in your profile (or system wide in /etc/bash.bashrc) should solve the problem going forward.

I hope this helps.

Regards,

Clifford

cliffordw · 08-28-2014, 07:36 AM

Hi again,

You can easily verify whether the timestamps are being saved. They're saved in your ~/.bash_history file with the rest of the info, in the form of comment lines like this:

Code:

#1408637756
ls -lrt
#1408637765
tail Xorg.0.log
#1408637882
alacarte

The numbers like 1408637882 are the timestamps, in seconds since the Unix epoch.

Habitual · 08-28-2014, 09:38 AM

Quote:

Originally Posted by thomas2004ch

as I look the history deeply I found all the command in the history list have the same Time Stamp.

The answer is correct and the report detail is expected.
This is what happens when you first enable history timestamping. It all gets stamped the hour/minute/second that bash re-reads ~/.bash_history.

Successive commands will show a different h:m:s on commands.

thomas2004ch · 08-29-2014, 01:33 AM

Quote:

Originally Posted by Habitual

The answer is correct and the report detail is expected.
This is what happens when you first enable history timestamping. It all gets stamped the hour/minute/second that bash re-reads ~/.bash_history.

This is not partly true. Why? As I call the history today, I got followings:

Code:

...
  976  2014-08-29 07:22:36 yum info java-1.7.0-oracle-devel
  977  2014-08-29 07:22:36 top
  978  2014-08-28 11:42:03 history
  979  2014-08-28 11:42:05 HISTTIMEFORMAT="%Y-%m-%d %T "
  980  2014-08-28 11:42:06 history
  981  2014-08-29 07:22:36 history
  982  2014-08-29 07:22:36 cd
  983  2014-08-29 07:22:36 vim .bashrc
  984  2014-08-29 07:22:36 history
  985  2014-08-28 11:43:02 history
  986  2014-08-28 11:46:08 vim .bashrc
  987  2014-08-28 11:48:20 history
  988  2014-08-28 11:52:23 man bash
  989  2014-08-28 11:52:43 man bash
  990  2014-08-28 11:53:46 history
  991  2014-08-28 11:53:56 free
  992  2014-08-28 11:53:58 history
  993  2014-08-28 11:54:07 df -h
  994  2014-08-28 11:54:08 history
  995  2014-08-29 07:22:41 history
  996  2014-08-29 07:23:08 ls -la
  997  2014-08-29 07:23:10 history
  998  2014-08-29 07:27:12 cd
  999  2014-08-29 07:27:13 ls -la
 1000  2014-08-29 07:27:21 ll .bash_history
 1001  2014-08-29 07:27:25 less .bash_history
 1002  2014-08-29 07:27:42 history
...

One can see, some of the earlier commands have the time stamp from today, and some later commands have time stamp from yesterday. This is not logical.

thomas2004ch · 08-29-2014, 01:37 AM

Quote:

Originally Posted by cliffordw

Hi again,

...
Setting it in your profile (or system wide in /etc/bash.bashrc) should solve the problem going forward.
...
Clifford

I use RHEL, there is no such file "bash.bashrc". I put the "HISTTIMEFORMAT="%Y-%m-%d %T "" in the ~/.bashrc as you told yesterday. Seems this is not enough?

thomas2004ch · 08-29-2014, 01:48 AM

Quote:

Originally Posted by cliffordw

Hi again,

You can easily verify whether the timestamps are being saved. They're saved in your ~/.bash_history file with the rest of the info, in the form of comment lines like this:

Code:

#1408637756
ls -lrt
#1408637765
tail Xorg.0.log
#1408637882
alacarte

The numbers like 1408637882 are the timestamps, in seconds since the Unix epoch.

Yes, I see the numbers (time stamps) in the ~/.bash_history file now. But I find they are not match with that from 'history'. Here is the example. When I open the .bash_history I got:

Code:

...
#1409218923
history
#1409218925
HISTTIMEFORMAT="%Y-%m-%d %T "
#1409218926
history
history
cd
vim .bashrc
history
#1409218982
history
#1409219168
vim .bashrc
#1409219300
history
#1409219543
man bash
#1409219563
man bash
#1409219626
history
#1409219636
free
#1409219638
history
#1409219647
df -h
#1409219648
history

But as I run the command 'history', I got:

Code:

...
  978  2014-08-28 11:42:03 history
  979  2014-08-28 11:42:05 HISTTIMEFORMAT="%Y-%m-%d %T "
  980  2014-08-28 11:42:06 history
  981  2014-08-29 07:22:36 history
  982  2014-08-29 07:22:36 cd
  983  2014-08-29 07:22:36 vim .bashrc
  984  2014-08-29 07:22:36 history
  985  2014-08-28 11:43:02 history
  986  2014-08-28 11:46:08 vim .bashrc
  987  2014-08-28 11:48:20 history
  988  2014-08-28 11:52:23 man bash
  989  2014-08-28 11:52:43 man bash
  990  2014-08-28 11:53:46 history
  991  2014-08-28 11:53:56 free
  992  2014-08-28 11:53:58 history
  993  2014-08-28 11:54:07 df -h
  994  2014-08-28 11:54:08 history
  995  2014-08-29 07:22:41 history
  996  2014-08-29 07:23:08 ls -la
  997  2014-08-29 07:23:10 history
  998  2014-08-29 07:27:12 cd
  999  2014-08-29 07:27:13 ls -la
 1000  2014-08-29 07:27:21 ll .bash_history
 1001  2014-08-29 07:27:25 less .bash_history
 1002  2014-08-29 07:27:42 history
 1003  2014-08-29 07:34:56 ll /etc/ba*
 1004  2014-08-29 07:35:26 find / -name "bash.bashrc"
 1005  2014-08-29 07:39:02 cd
 1006  2014-08-29 07:39:05 less .bash_history
 1007  2014-08-29 07:42:32 grep # .bash_history
 1008  2014-08-29 07:42:42 grep '#' .bash_history
 1009  2014-08-29 07:42:46 grep '#' .bash_history | wc -l
 1010  2014-08-29 07:42:50 history
 1011  2014-08-29 07:43:24 less .bash_history
 1012  2014-08-29 07:43:46 history
 1013  2014-08-29 07:44:03 less .bash_history
 1014  2014-08-29 07:44:29 cd
 1015  2014-08-29 07:44:32 ls -la
 1016  2014-08-29 07:44:36 less .bash_history
 1017  2014-08-29 07:46:28 less .bash_history
 1018  2014-08-29 07:47:17 history

Why?

cliffordw · 08-31-2014, 02:55 AM

Hi there,

As far as I know, the shell reads the history from the file when it starts, then keeps track of the history in memory, and only saves it to the file again when you exit.

This means you will see entries in the output from the history command which is not saved in the file yet. It also means you might not see what you expect in the history if multiple sessions use the same history file (which is the default). There's an explanation and possible solution (which I haven't tried) at http://linuxcommando.blogspot.com/20...-multiple.html.

You could also change HISTFILE to unique names if you prefer. This is great if you main goal is to record the history for audit purposes, but usually means you can't pick up your old history from a new session, making it less convenient to use.

Regards,

Clifford

unSpawn · 08-31-2014, 06:02 AM

Quote:

Originally Posted by cliffordw

You could also change HISTFILE to unique names if you prefer. This is great if you main goal is to record the history for audit purposes,

Any part in the chain that provides the audit trail should be trustworthy and any alteration should be impossible. Since in this example the login shell is started by the user and the user can alter quite a few aspects I would disagree as there's absolutely no guarantee of log trail integrity whatsoever. (If you're interested search for posts combining the audit service, 'rootsh' and remote logging.)