Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Aug 2008 11:40:29 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-current@freebsd.org, gary.jennejohn@freenet.de
Subject:   Re: Enormous utmp since mpsafetty
Message-ID:  <200808291140.30158.jhb@freebsd.org>
In-Reply-To: <20080827161940.1b4403ee@peedub.jennejohn.org>
References:  <20080826124335.GD3305@carrot.paeps.cx> <alpine.BSF.1.10.0808271248200.96701@fledge.watson.org> <20080827161940.1b4403ee@peedub.jennejohn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 August 2008 10:19:40 am Gary Jennejohn wrote:
> On Wed, 27 Aug 2008 12:50:17 +0100 (BST)
> Robert Watson <rwatson@FreeBSD.org> wrote:
> 
> > On Wed, 27 Aug 2008, Ollivier Robert wrote:
> > 
> > > According to Gary Jennejohn:
> > >> There are many more pseudo-ttys in /etc/ttys now.  AFAIK utmp allocates 
an 
> > >> entry for every one of them at startup.
> > >
> > > utmp concepts are ancient.  It is indexed by the tty/pty number so can 
grow 
> > > rather large but it should be a sparse one too.  I remember talks about 
> > > replacing it with something a bit more modern.  Backward compatibility 
is 
> > > assured through login(3) although it would break programs digging in the 
> > > utmp file itself.  SVR4 had utmp/utmpx and setutline/getutline BTW...
> > 
> > Right -- utmp growing to 256K would be an excellent example of utmp format 
> > inefficiency.  On the other hand, utmp growing to 998M is probably an 
example 
> > of a bug rather than an inefficient design.  freefall.FreeBSD.org, a 
> > relatively busy shell box, has a utmp of around 5k, so common use doesn't 
> > generally exercise that inefficiency...
> > 
> 
> But freefall is running FreeBSD 7.0-STABLE #34: Sat Apr 12, so it doesn't
> have the new tty stuff running, although I don't suppose that completely
> explains the gigantic utmp which OT reported.

The new pts entries are after all the 256 pty entries in /etc/ttys, so utmp 
may be larger becuase the pts entries are "later" in the file (higher 
offsets).  However, if the file is sparse, then it doesn't actually hurt 
anything.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808291140.30158.jhb>