10

Just noticed some 640MB wtmp file in a virtual container (Ubuntu Hardy).

# last -n 10000 -f /var/log/wtmp.1|wc -l
384
# ls -hl /var/log/wtmp.1
-rw-rw-r-- 1 root utmp 641M 21. Sep 07:49 /var/log/wtmp.1

logrotate was not installed (I just did that and forced rotating).

Are there records in there not being displayed by last (which should show the last 1000 entries, but apparently there are only 384).

From quickly skimming the wtmp/utmp man page, it does not look like a single entry should use about 1,6MB.

Is there another program besides last to inspect these files?

4 Answers 4

8

logrotate was a good idea.

Like any regular file, wtmp could have been "sparse" (cf. lseek(2) "holes" and ls -s) which can show a extreme file size that actually occupies little disk. How did the hole get there, if it was a hole? getty(8) and friends could have had a bug. Or a system crash and fsck repair could have caused it.

If you are looking to see the raw contents of wtmp, od or hd are good for peeking at binaries and have the happy side effect of showing long runs of empty as such.

Unless it recurs, I wouldn't give it much more thought. A marginally competent intruder would do a better job than that, the contents aren't all that interesting, and little depends on them.

1
  • The file does not appear to be sparse: here is the beginning of the new file (already 23MB): pastebin.com/NFtnyUJU If I understand this correctly, it looks like a bunch of logins? (6=LOGIN_PROCESS). The machine is a OpenVZ container, running BOINC (distributed computing), so this might be just as expected. There was another machine with a huge wtmp file (phpmyadmin, web server), where the output of hd looks more odd: pastebin.com/1UtxYudE
    – blueyed
    Sep 22, 2010 at 11:21
7

Just to help others which might find this useful...

Is there another program besides last to inspect these files?

Yes, try utmpdump.

$ utmpdump /var/log/wtmp
2

If you doubt the wtmp might have holes you could get rid of them with cp --sparse if you have new enough coreutils, or with fallocate --dig-holes if you use yet not released util-linux 2.25 version. Perhaps more practical approach is to repack the wtmp.

utmpdump /var/log/wtmp | utmpdump -r > /tmp/newtmp
ls -l /var/log/wtmp /tmp/newtmp # if significantly smaller
chown root:root /tmp/newtmp
chmod 0554 /tmp/newtmp
mv /tmp/newtmp /var/log/wtmp

And if even then the file is rather large then just rotate & compress.

mv /var/log/wtmp{,.1}
gzip -9 /var/log/wtmp.1
0

utmp is usually sparse - its records are indexed by the major+minor device numbers of the controlling terminal of the session. This ensures that "stale" records that fail to be erased during logout will still eventually get overwritten eventually, by the next session on the same terminal.

It can safely be erased each time the system is booted; arguably it should be /run/utmp but most distros don't put it there (yet).

wtmp is not normally sparse, since it's a log that's appended each time there's an event. Since its records are a fixed size, it's easy to read them in reverse order to show "most recent first".

Both files have the same record format, so you can use less -f /var/log/whatever to read from a particular file.

It doesn't do any harm if wtmp is sparse, since the holes just read as all-bytes-zero which is just ignored. However holes may indicate lost records due to an abrupt system shutdown (metadata flushed but content lost).

The x suffixed variants have a larger record structure (the old ones didn't have room to hold an entire IPv6 address or a reasonable FQDN), but otherwise behave similarly. Some versions of last can read both record structures.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .