Subject: Re: increasing UT_HOSTSIZE for IPv6?
To: None <>
From: Christos Zoulas <>
List: tech-userlevel
Date: 07/23/1999 18:24:39
In article <199907231706.LAA11376@forge.BSDI.COM>,
Chris Torek <torek@BSDI.COM> wrote:
>I seem to recall that SysV now has a text-based umtp-equivalent
>file ("utmpx"), with the old utmp stuff around for compatibility.
>This seems like it might be the way to go, if it is not too badly
>broken.  Among other things, it could remove the length limits
>entirely, if the API uses dynamic allocation.
>Anyone have details on this?

Utmpx is not a text based file. It is an enriched version of utmp.
Solaris supports both utmp and utmpx by means of utmpd (bleh) which
gets requests to write utmp records from pututline() or pututxline(),
via a named pipe. It also polls /proc to determine if processes
die, so that it can cleanup in case programs that added entries
were not able to do so.

This is an example of an svr4 utmpx:

struct utmpx  {
	char    ut_user[32];		[login, or status string]
	char    ut_id[4]; 		[4 inittab]
	char    ut_line[32];		[tty]
	pid_t   ut_pid;			[creator's pid]
	short   ut_type;		[type of entry]
	struct  exit_status ut_exit;	[exit status]
	struct  timeval ut_tv;		[time entry was created]
	long    ut_session;		[session id]
	long    pad[5];			[reserved]
	short   ut_syslen;		[length of hostname?]
	char    ut_host[257];		[hostname]

I really don't think we should go the utmpd way, it still does not
work properly in all the cases. Let's not forget about wtmp which
stores utmp entries, and lastlog which stores struct lastlog and
will need to be modified too. It is a big can of worms, that is
why nobody has attacked it yet.

An ascii format will not be convenient for lastlog and wtmp, because
of the variable length records. I would think that a db(3) file
could be a nice solution, but unfortunately the db version 1 does
not support locking and db version 2 does not come with an acceptable
license for inclusion to the base source.

The only alternative left is to create an enhanced version with fixed length
records of larger size. Moving to the SVR4 like utmpx is not a bad idea,
because programs key of the SVR4 defines to discover supported fields, so
less third party code will need to be altered.