utmp patch [ was: Re: TODO list proposal for volunteers ]
T.D.Lee at durham.ac.uk
Fri Oct 6 12:25:59 GMT 2000
On Fri, 29 Sep 2000, Gerald Carter wrote:
> David Lee wrote:
> > [...]
> > If someone's patch fails to apply to the current
> > production release then there is a reasonable
> > expectation for them to fix their patch. But if it
> > does apply cleanly, who is responsible for reconciling
> > it with the emerging next release?
> We're hoping that the author of the patch will (what if
> I said please?) :-)
[ Gerald and I have since had a private discussion. I believe he has
looked at the utmp patch (a) to confirm that it is, at least, clean
against 2.0.7 and (b) possible incorporation. ]
I have tried to rework the post-2.0.7 utmp patch for CVS SAMBA_2_2. It
was non-trivial, but I have got most of it done.
But I have hit a fundamental problem and would like your advice.
In the old "smbd/connection.c", claim_connection() neatly worked out a
unique number "foundi", scanning from 0 and looking for a free slot, which
was small, but unique across connections not only within an smbd process
but, vitally, across all smbd processes. The utmp stuff then hitched a
lift on this number, as the fundamental basis of generating the utmp/utmpx
record. (Likewise, yield_connection() had a corresponding algorithm for
finding and freeing that record.)
But the new "smbd/connection.c" uses the new tdb code. There is now no
longer any access to such a small, unique-across-and-within-processes
number. (The number used is only unique within the process, not
across them.) Help!
Indeed, my initial trial, replacing 2.0.7 smbd with 2.2, verifies this;
utmp records from processes overwrite each other.
The only way I can see around this is to have another tdb database and
attempt "tdb_store(..., TDB_INSERT)" on ascending numbers until success.
(Similar to what the old code does, but probably less efficient.)
Any other ideas, anyone?
If that idea seems OK (or least bad), I'll try to work around this changed
(2.0.7 -> 2.2) functionality by implementing it.
But it would be worth, I think, trying to get the rest of the fixes
("configure.in" stuff etc.) incorporated into 2_2 ahead of that, so that
I'm only chasing one moving target rather than four or five...
: 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. :
More information about the samba-technical