wtmp/last weird behavior

[Jerry Feldman]

It has been a while. I used to maintain the utmp, utxtmp code in True64
Unix. wtmp is implemented as a flat file where every record is appended
to it.
One suggestion is to log yourself in and do a who, log 1 kid in, again
do a who, and thirdly log ther other kid in and do a who. Then go back
and check wtmp using last, and see if all 3 logins are there. Also, try
using the lastlog command. While this uses a different file, it might
also show you some interesting information.

BTW: utmp and wtmp have been around Unix for a very long time. The
current standard is utmpx.



On 08/15/2014 09:41 PM, David Rysdam wrote:
> You replied only to me. I hope it isn't too gauche to reply to the
> list. I like these things to be searchable by others in the future. (Ob:
> http://xkcd.com/979/)
>
> Bill Freeman <ke1g.nh at gmail.com> writes:
>> But you are probably talking about an Xdm (gdm, kdm, etc.) login.  I'll bet
>> that code works pretty well too.
> Yes, I am. That's what I thought as well. It looks like wtmp is a
> "standard" of fairly long-standing, so I'd expect it to work right.
>
>> So I can think of two possibilities:
>>
>>   1. One kid is letting another kid just go  ahead and use the logged in
>> session, rather than logging out and making the other log in.
> Definitely not happening. And even if it were, it can't be happening
> 100% of the time. 'last' reports that one of the children hasn't logged
> in *even once* since the 1st, even though I've watched him do it.
>
>>   2. Some of them are using switch user, rather than logging out and
>> logging in.  I don't know what happens to wtmp when you switch back to an
>> existing session. If it doesn't make a wtmp entry, that might b e construed
>> as a gdm bug (or whoever it is that offers "switch users").  Or not.  A
>> case could be made that suspending and resuming a user's session does not
>> constitute a log out and in.  Even if this is what's going on.
> This definitely has happened, but as above not 100% of the time for any
> given child. Maybe 1% of the time (their computer is right next to our
> computers, so we see the nominal behavior).
>
>> I think that you want a tool that prints the file in human readable form,
>> whose output you can pipe into tail, or look at in your favorite editor, so
>> that you can see the sequence.  If you can't find such a tool, the utmp
>> wtmp man page gives a C structure for the entries in the file.  If you have
>> the missing kid turn up as logged in for days at a time, it's probably the
>> switch users thing.
> I saw the layout, but since 'strings /var/log/wtmp' doesn't show the
> child, I'm skeptical that a program will find it. I can try it. Or at
> least read the structure a little more closely and see if the UID could
> be in there. For one particular child. This month only.
>
>> Another interesting diagnostic would be a tool that captures the last entry
>> in wtmp to a private log of your own that you arrange to have run when they
>> log in - .bash_profile and the X equivalent.
> Maybe wtmp is getting overwritten? I guess that could be. I have no idea
> how it's getting captured in the first place...
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20140816/d2ce60c0/attachment.bin