In which I half-provide context, half rant
You're running into an example of the main reason I don't like managing Solaris systems: Nothing is ever just easy.
I don't know if the locale's really going to do anything except change the order of certain portions of the timestamp around. I'm interested if anyone knows of a way to coax Solaris's last
into giving the year, but I'm not going to hold my breath. Sun's software development mantra seems to have been "It Technically Works."
Sun seems to have pretty much developed something right up to the point absolutely required of them, and then pretty much stopped there. So you end up with generally accepted solutions being like these and you just keep a listed collection of workarounds for common problems.
The only way I've ever found of doing this is to use /usr/lib/acct/fwtmp
to dump the entire contents of /var/adm/wtmpx
to a pipe to some other program that I use for manipulating the text output (grep
, tac
, sed
, etc).
Bonus: Since seeking the end of the file and just moving back by the fixed wtmpx
record length would be asking too much, fwtmp
can only print out the contents of wtmpx
as they appear in the file. So you have to use some other means (probably tac
) of reversing the lines, unless you're actually interested in the oldest information (which is the least likely use case, but I digress).
Depending how long your system has been in operation wtmpx
might be kind of large, so you may want to go get a cup of coffee, maybe go check to see if your tires are underinflated, and maybe go read a book or two while you're at it.
The Actual Answer to your question:
This is a command that emulates last
in way that is usable to most people interested in looking at login records:
# cat /var/adm/wtmpx | /usr/lib/acct/fwtmp | tac | head
You'll notice I have to pipe wtmpx
in since they don't give you a means of just giving the file to fwtmp
. That's because feeding it in via stdin
Technically Works™ in the majority of use cases and they wouldn't have had to write a few extra lines of code. So they'd rather just make Admins do that.
This is example output of the above on on of the systems I look after:
[root@atum root]# cat /var/adm/wtmpx | /usr/lib/acct/fwtmp | tac | head
jadavis6 ts/1 pts/1 19410 7 0000 0000 1382723864 157168 0 19 ditirlns01.xxx.edu Fri Oct 25 13:57:44 2013
jadavis6 sshd 19404 7 0000 0000 1382723864 133973 0 19 ditirlns01.xxx.edu Fri Oct 25 13:57:44 2013
oracle sshd 6640 8 0000 0000 1382713401 157107 0 0 Fri Oct 25 11:03:21 2013
oracle ts/1 pts/1 6647 8 0000 0000 1382713401 150489 0 0 Fri Oct 25 11:03:21 2013
oracle ts/1 pts/1 6647 7 0000 0000 1382712445 24488 0 23 a0003040148735.xxx.edu Fri Oct 25 10:47:25 2013
oracle sshd 6640 7 0000 0000 1382712442 304729 0 23 a0003040148735.xxx.edu Fri Oct 25 10:47:22 2013
jadavis6 sshd 23537 8 0000 0000 1382560970 410725 0 0 Wed Oct 23 16:42:50 2013
jadavis6 ts/1 pts/1 23544 8 0000 0000 1382560970 404795 0 0 Wed Oct 23 16:42:50 2013
jadavis6 ts/1 pts/1 23544 7 0000 0000 1382552999 619524 0 19 ditirlns01.xxx.edu Wed Oct 23 14:29:59 2013
jadavis6 sshd 23537 7 0000 0000 1382552999 602215 0 19 ditirlns01.xxx.edu Wed Oct 23 14:29:59 2013
[root@atum root]#
EDIT:
I know I'm whining about something small up there, but after a while I just get tired of every little thing (such as simply asking "what's the year?") turning into an hour long googlefest or something that's more or less just tribal knowledge (such as the existence of fwtmp
).
Best Answer
No, the last line doesn't report the I/O wait time but is hardcoded to display zero on Solaris, whatever the actual load.
With the generalization of multi-core and multi-thread CPUs,
I/O wait
time ceased to have real meaning and even risked to be misleading. I/Os are usually not bound to a single CPU unit so there is no specific CPU waiting for an I/O when one or more of them are pending. In any case, only processes are waiting for I/Os to complete, this wait doesn't use any CPU cycles so technically, CPUs are idle and available for other tasks during that time. I/O not being distinguishable from idle time is then reported to be equal to zero starting from Solaris 10, and then what used to beI/O wait
is now included in the CPU idle time, which it is really.If you are concerned about I/Os, have a look to disk statistics with
iostat
(e.g.iostat -xntc 5
and look to the service timesvc_t
, number of I/Os in the wait queuewait
and percentage of time the queue is not empty%w
) , not the CPU statistics reported byvmstat
,sar
,top
,iostat
and the likes.This article might also be of interest to investigate I/O performance issues: http://dtrace.org/blogs/brendan/2011/05/11/file-system-latency-part-1/
This one is explaining that the issue is the same with Linux.