poking/prodding utmp

[David Lee]

On Wed, 5 Apr 2000, Freddie wrote:

> > > Normally, with utmp support enabled, it sets the user's "line" to
> > > "smb/<connid>". What's wrong with that? Well, you end up with something
> > > like this: (or something close to it)
> > >
> > > freddie  smb/1    zugzug           Tue 2am  0.00s 13days   ?     -
> > > freddie  smb/8    bouncy            6:20am  0.00s 13days   ?     -
> > > lewi     smb/11   narf             Sun 5pm  0.00s 13days   ?     -
> > >
> > > It varies depending on the number of shares the client machine is
> > > accessing. I shudder to think what you'd end up with when a hundred or so
> > > people connect.... so I wrote another patch... and now I get:
> > >
> > > freddie  smb/2    zugzug           Tue 2am  0.00s 13days   ?     -
> > > freddie  smb/3    bouncy            6:20am  0.00s 13days   ?     -
> > > lewi     smb/4    narf             Sun 5pm  0.00s 13days   ?     -
> > > [...]
> > > This involved adding another function, static int utmp_line(void), which
> > > returns an int (obviously), which is the next smb/<n> that we can use. 
> > Tada.
> > >
> > > The question is, should this be a seperate option, part of utmp
> > > consolidate, or just always on? I'd vote for having it always on (well, if
> > > utmp = Yes).
> >
> >Yet another option??  The advantage of the earlier scheme is that it
> >matches the internal connection number (geek-friendly).  The advantage of
> >the latter is that it is more obvious to the casual outside observer
> >(including most sys.admins most of the time, I guess).
> >
> >The emerging code has always implemented the former (the "sparse"
> >numbers) for the brilliant reason that it was trivial to code.  But my
> >experience suggests that your latter (sequentially ascending, filling in
> >the gaps) is probably preferable.  (We have several hundred simultaneous
> >connections, though usually only one share per connection.)
> 
> >Any strong views, anyone?  My own leaning is towards Freddie's (i.e. the
> >latter) scheme.  Do we really want another option?
> 
> For the moment, it's not another option, it's part of the "utmp 
> consolidate" option. If you turn that on, you get the sequential ut_line's 
> to go with it :)

I hope you have seen that the patch (for 2.0.7pre3) is now available.
Notes at:
    http://www.dur.ac.uk/~samba/utmp-207pre3.2.htm
and patch at:
    http://www.dur.ac.uk/~samba/utmp-207pre3.2.patch

(the ".2" is version 2 of my patch).

1.  Although it has utmp consolidate (please test), it still uses the
    sparse numbering scheme.  I believe that your "next sequential slot"
    code has a race condition, between finding the slot and grabbing it. 
    (imagine connections arriving simultaneously in different processes
    and the CPU timeslicing between the finds and grabs).  So for the
    moment I think we'll have to miss on that particular feature.

2.  Rather than using your new function in "conn.c" to count connections
    within the process, it uses an exisitng one.  It seems to work.

Could you try the patch and report back?  (Jeremy is keen to move quickly
on incorporating it.)  Thanks.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :