[comp.unix.aix] utmp fix?

mcover@magnus.acs.ohio-state.edu (Mark Coverdill) (05/30/91)

   Ok, what gives?  I just upgraded our machine (RS6000/320) to
AIX 3.1.5 and I was under the impression that the bug in the utmp
file would be fixed with this release, however it is still there.

   For a recap, apparently anyone using the 64-port asynchronous
controller will show an incorrect entry in the IDLE column (currently
my system show various users as logged in for 26 days even though
in reality they just logged in) when using the "w" command and
several messages I have seen have traced this to the utmp file or
the wtmp file.

   I typed in a program I saw about two weeks back to fix this
problem but that had no effect and have been unable to locate it
in various archives. Soooo, if someone would kindly repost the
entire procedure on how to do this or tell me where I can ftp
the procedure to cleanup the utmp file I would appreciate it.

   It doesn't sound like a big deal, but I discovered that one of
our commands in an application we are running is broken because
it relies heavily on the utmp file to determine if someone is 
logged on.

   Thanks for your support.
-- 
Mark Coverdill                                  The Ohio State University
Internet: mcover@magnus.acs.ohio-state.edu             Columbus, Ohio

jfh@rpp386.cactus.org (John F Haugh II) (06/02/91)

In article <1991May30.011132.28981@magnus.acs.ohio-state.edu> mcover@magnus.acs.ohio-state.edu (Mark Coverdill) writes:
>   I typed in a program I saw about two weeks back to fix this
>problem but that had no effect and have been unable to locate it
>in various archives. Soooo, if someone would kindly repost the
>entire procedure on how to do this or tell me where I can ftp
>the procedure to cleanup the utmp file I would appreciate it.

This is a program that I use here to keep my utmp file clean.  I
posted it once before and someone at IBM brushed it up and made
it look pretty.  Here it is again ...
-- 
#include <sys/types.h>
#include <utmp.h>
#include <fcntl.h>

main ()
{
	int	fd;
	struct	utmp	utmp;

	while (1) {
		if ((fd = open ("/etc/utmp", O_RDWR)) < 0)
			exit (1);

		while (read (fd, &utmp, sizeof utmp) == sizeof utmp) {
			if (utmp.ut_type == USER_PROCESS &&
					kill (utmp.ut_pid, 0) != 0) {
				lseek (fd, - (long) sizeof utmp, 1);
				utmp.ut_type = DEAD_PROCESS;
				write (fd, &utmp, sizeof utmp);
			}
		}
		close (fd);
		sleep (60);
	}
}
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."

mcover@magnus.acs.ohio-state.edu (Mark Coverdill) (06/03/91)

In article <19352@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
>This is a program that I use here to keep my utmp file clean.  I
>posted it once before and someone at IBM brushed it up and made
>it look pretty.  Here it is again ...
>-- 
 [ program deleted ]

As a followup to my original posting about the utmp file,  I called 
Defect Support at IBM about this problem.  They said that they indeed
knew about the problem and the fix didn't make it into 3005 but would
be glad to send me 2006 (I guess this is the title for intermediate
fixes between major fixes??).  I applied 2006 and now everything works
like a charm!  They even sent the fix by overnight mail so all told the
problem was solved in less than 48 hours, even faster than the net on
this particular occasion (score one for IBM :-)).

BTW, 2006 was more than just a fix to the utmp file, much more.  It was
late Friday afternoon so I didn't get a chance to scan the change list
but many of the major lpp's such as bos.obj, etc. were brought up to
003.0006.0012 (I think?) not to mention it took close to an hour to
upgrade (much to my surprise!).

Anyway, I'm happy, my users are happy and the computer is happy, so those
of you with the same problem can look for 2006 or possibly 3007 in the
not so distant future :-)

A big thanks to all those who responded...

Mark

BTW, the system is an RS 6000/320 running AIX v3.1.5/2006.

-- 
Mark Coverdill                                  The Ohio State University
Internet: mcover@magnus.acs.ohio-state.edu             Columbus, Ohio