On Nov 21,  2:51am, jnemeth@victoria.tc.ca (John Nemeth) wrote:
-- Subject: Re: sample utmpx implementation

|      How would you deal with wtmpx?  Since it is often rotated, you
| can't depend on a special record being first in the file.  I suppose
| you could make people read utmpx to get the version, but I'm not sure
| that would work in practice.

The write routine could check for that before writing the next entry.

| } - The lastlog stuff is missing
| }       I am thinking of implementing lastlog using db, so that it does not
| }       become huge like it is now.
| 
|      lastlog is a constant size.  It also has holes, so it isn't any
| larger then needed.  Making it a db would greatly increase the size and
| considerably complicate access.  I really don't like this idea.  Also,
| any reason you didn't add any padding to struct lastlogx?  Off the top
| of my head, I can't think of any other fields that are needed, but that
| is the whole reason for padding.

You are right, I will add padding. I am not sure about the complicating
access issue. I'd rather have a routine abstracting the complex access,
than exposing the simplistic access method we currently have. Having
huge files with holes does not appeal to me.

| } - I also don't know what to do about utmpd. pututent() is supposed to
| }   register utmpx entries with utmpd, and utmpd is supposed to detect
| }   that processes have died and change the ut_type field appropriately.
| }   Is that something we want?
| 
|      Is this something we really need?  Or, could we just have init
| reap the entry when it reaps the process?

It is not necessarily init that reaps the process, because the parent
can do that too. To avoid this problem solaris uses utmpd and I think
that the utmp libc routines notify utmpd about the processes it needs
to watch. I am not sure about that though.

|      I didn't see any functions for handling wtmpx records.  Solaris
| 2.5 provides these functions:
| 
|   updwtmp()
|      Checks the existence of wfile and its parallel  file,  whose
|      name  is  obtained  by appending an ``x'' to wfile.  If only
|      one of them exists, the second one is created  and  initial-
|      ized  to  reflect  the  state  of the existing file. utmp is
|      written to wfile and the corresponding  utmpx  structure  is
|      written to the parallel file.
| 
|   updwtmpx()
|      Checks the existence of wfilex and its parallel file,  whose
|      name  is obtained by truncating the final ``x'' from wfilex.
|      If only one of them exists, the second one  is  created  and
|      initialized to reflect the state of the existing file. utmpx
|      is written to wfilex, and the corresponding  utmp  structure
|      is written to the parallel file.
| 
| I'm not sure what else should be provided.  Although something to get
| the most recent login/logout pair for a user would probably be good.

Ok, I'll look into implementing those.

christos