Last command displays wrong information

UNIX Solaris
1

Hi am having Solaris10 - Sun-Fire-V890 server, the information displayed by Last command is wrong how do i get this sorted without loosing any datas..

# uptime
 12:32am  up 20 day(s), 33 min(s),  1 user,  load average: 1.54, 1.82, 1.93
# last reboot
reboot    system boot                   Sat Jun  7 23:12
reboot    system down                   Sat Jun  7 23:10
reboot    system boot                   Sun Jun  1 00:12
reboot    system down                   Sat Jun  7 23:09
reboot    system boot                   Sun Jun  1 00:12
# date
Sat Jul 30 00:32:56 CDT 2011

---------- Post updated at 04:34 AM ---------- Previous update was at 01:35 AM ----------

guru's please help..

2

On Solaris 10

The information that last uses resides in
/var/adm/wtmpx

the information for uptime is in:
/var/adm/utmpx

The disparity you see is not a big deal. It means someone did something to one of the files; it does not mean there is something horribly wrong with your system

1 Like
3

Fix your corrupt wtmpx file. The usual reason for having one is /var file system being almost full while some event is logged in wtmpx.

I haven't tried it but you might get help with that tool:
martin carpenter / projects / ckwtmpx

1 Like
4

Solaris also provides system tool for fixing wtmpx. Check

man wtmpfix
1 Like
5

AFAIK, wtmpfix can fix corrupted entries but not truncated ones, i.e. those that make the newer logs unreadable by regular tools.

Edit: After looking at its source code, wtmpfix does actually fix truncated entries too.

Cross Reference: /onnv/onnv-gate/usr/src/cmd/acct/wtmpfix.c

1 Like
6

Thanks all, for helping me ..
Bartuss11: how do i use wtmpfix command.. will it lead to server reboot or loss in the data which is there in wtmpx file.

I even checked the size of wtmpx file its 6M file..

7

You use it like this:

cp /var/adm/wtmpx /var/adm/wtmpx.bak
/usr/lib/acct/wtmpfix /var/adm/wtmpx > /var/adm/wtmpx.tmp
mv /var/adm/wtmpx.tmp /var/adm/wtmpx

No reboot is required. If there is some problem with last command after this operation, you can simply restore the file from the backup copy:

cp /var/adm/wtmpx.bak /var/adm/wtmpx
1 Like
8

Might be worth a look at the raw records with the "fwtmp" command to make sure that they are from this year:

cat /var/adm/wtmpx | fwtmp | grep "boot"

Further to jlliagre the process turns itself off if there is not enought disc space and fails if the file reaches 2 Gb. Actually 6 Mb seems small unless there is little activity on the server or a maintenance script in place. It is possible for a badly written maintenance script to corrupt this file or disassociate this file from the active logging process or even change the permissions so that the logging process does not work.
Have you had a disc space crisis in the disc partition containing directory /var/adm ?

1 Like
9

# df -h /var
Filesystem size used avail capacity Mounted on
/dev/md/dsk/d3 4.9G 2.9G 2.0G 60% /var

Possibly /var could be full or out of space when wtmpx and utmpx event logging happened.

---------- Post updated at 02:29 AM ---------- Previous update was at 01:32 AM ----------

Hi Bartus11
after performing the steps u mentioned it seems like wtmpx file got nullified and last reboot was giving this output,
# last reboot
wtmp begins Sun Jul 31 00:41
Thanks we have taken backup and i got my datas back.

---------- Post updated at 02:30 AM ---------- Previous update was at 02:29 AM ----------

Hi Bartus11
after performing the steps u mentioned it seems like wtmpx file got nullified and last reboot was giving this output,
# last reboot
wtmp begins Sun Jul 31 00:41
Thanks we have taken backup and i got my datas back.

10

Hi,

Author of the ckwtmpx program mentioned above here.

This is correct. However there were a couple of things that I found sub-optimal:

  1. wtmpfix(1M) is too aggressive. I have a test corrupt wtmpx file as "found in the wild" of 6.7M. Processing with wtmpfix discards 6.3M of data. ckwtmpx on the other hand discards 742 _bytes_ and the resulting file certainly appears valid (it processes correctly with last(1) or fwtmp(1M), no errors, no truncation).
  • wtmpfix's re-alignment jumps forward by one record plus however many bytes remain after removing a complete number of records from the file (the residue in the source quoted above). ckwtmpx's strategy is to crawl forward byte by byte.
  • ckwtmpx's strategy to check "does this look like a valid record?" is less complex (strict?). See is_record_valid() in ckwtmpx.c (apparently I can't yet post URLs...).
  1. wtmpfix doesn't show what was discarded. I was interested in trying to work out where the corruption was coming from (ckwtmpx -e error_file). This didn't help. I know it isn't always lack of disk, and it isn't LARGEFILE (which I once suspected). The 742 byte example I quoted above contains (almost) two corrupt "system down" records with far too many NULL bytes.

Any problems with ckwtmpx, suggestions, patches, please hit me by email, mcarpenter@free.fr. Thanks!

1 Like