'last' command output issue

Hi there!

I have the following concern with 'last' command:

user1 sshd server1 Mon Sep 11 23:18 - 00:05 (00:46)
user2 pts/33 server2 Mon Sep 11 14:47 - 07:45 (4+16:57)

From the output shown above I understand the value between '()' responds to the duration of the session in a format such as (days+HH:MM). This is what I always knew and was also able to confirm from different executions. However, in the previous example something is wrong, because a duration of 4 days + almost 17 hours will make the logoff session time belong to Sep 16, which is in THE FUTURE. I have more examples from sessions starting in Sep11 and a duration expressed with (292+19:52) which makes it even worse.

Do anyone of you understand what can be the issue here? I'm I misunderstanding something? Did you ever faced something like this?

Note: This is being executed in Solaris10 OS.

last searches backwards through the wtmp logs, and the results are consequently presented rather strangely.

You can see the full start/end date/time pairs using last -F, which is easier to understand than the default listing.

However, I am on Linux (Mint 19.3). I checked Oracle Solaris man page, and it appears that the -F option is not supported, and the log filename is different. So some comments on the default listing might help.

If the start time and the end time are in the same day, the default output is obvious:

Sat Sep  9 08:36 - 23:28  (14:51)

If the session runs over two consecutive days, it shows the start date/time and the end time (no date) and duration. (I can check that because I shut down every night, and I can see a clear alternation between boot and session logs.)

Fri Sep  8 07:22 - 01:10  (17:48)

For sessions that run for multiple days, your duration 16:57 is the difference in the two times (including one midnight crossover), and the 4+ duration notation states that the start date is 4 days earlier than the date shown.

There may be a one-off error there, which you could check for by leaving a sleeping user login, and running a cron last job every six hours to see how the narrative progresses.

The uptime command would probably show you that the most recent boot was around 23-Nov-2022, so 292 days ago.

You can read the (binary) logs with last -f /var/log/wtmp and last -f /var/run/utmp.

My logs are rotated monthly, keeping one, so I only have /var/log/wtmp.1 covering August. Your server may keep more history that my Laptop.

This is Solaris - no last -F
I agree that something strange must have happened, like a leap in the system time, or a manipulation of the wtmpx file. Maybe it was subject to a log rotation? Look at logadm.conf and cron jobs.
Maybe there is a bug in the last command?

Thanks for your replies.

By doing some research about this behavior, I found these possible explanations:

• System Clock Issues: One possibility is that there are problems with the system's clock or time synchronization. If the system clock is incorrect or not synchronized with a reliable time source, it can lead to inaccurate timestamps in the wtmp log file.
• wtmp Log File Corruption: The wtmp log file might be corrupted or damaged. This corruption can cause incorrect or inconsistent data to be displayed when viewing login and logout times.
• Manual Editing of wtmp: In rare cases, manual editing of the wtmp log file by a user or administrator can result in incorrect timestamps or other anomalies in the output of the last command.
• Bugs or System Issues: There could be bugs or system issues that are causing incorrect timestamps to be recorded in the wtmp log file. This could be related to the specific version of the operating system or any updates or patches applied to it.

To address this issue and obtain accurate login/logout information, we should consider taking the following steps:

• Check System Clock: Ensure that the system's clock is correctly configured and synchronized with a reliable time source, such as an NTP (Network Time Protocol) server. Correcting any time discrepancies can help ensure accurate timestamps.
• Check wtmp File: Verify the integrity of the wtmp log file. If it's corrupted, you may need to restore it from a backup or take appropriate corrective measures.
• Investigate System Logs: Look into system logs and audit trails for any entries related to time synchronization issues, filesystem errors, or wtmp file anomalies.
• Update and Patch: Ensure that the operating system and all related packages are up-to-date with the latest patches and updates to address any potential software bugs.
• Monitor for Recurrence: After addressing the issue, monitor the last command output and system logs to ensure that the problem does not recur.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.