samba - Aug 1997 - SMBD not killing process

>>On Tue, 26 Aug 1997, Rob Naccarato wrote:
>
>then, you get [user2] created, but the share [user1] still exists!
>
>i have only been able to reproduce the problem, not fix it: i've sent 
>details, as best i can, to the other samba team people, so that those 
>more familiar with smbd (where the problem lies) can fix it.  in the 
>mean-time, i keep on hacking a local copy of smbd to see if i can narrow 
>this down some more.
>
So, what can I do in the meantime?  Go back to a previous version
of Samba?  Does a previous version  stop this from happening?
Are there any log files I can send along to help fix
this problem?  I concur with your observation about the smbd not
exiting properly.  During some tests, smbstatus showed us some
locked files without an associated client connected.
>> the client appears to not always make a connection to the
>> [netlogon] share to run the logon script.  It does, however,
>> always connect to [netlogon] to open the config.pol file, which
>> is always run after the logon script.
>
>[hm.  personal question: how did you get it to open / load the config.pol 
>file?]
>
The trick is to set "Load Balance" on the client (in Poledit or
in the Registry).  This setting is found in Poledit under
Local Machine->Network->Update.  Set Update to Automatic and
Load Balance on. Then have config.pol in the [netlogon] share,
readable by world.  
>Kixtart (hur hur).  is that the program that modifies the registry?  
>particularly, it's being suggested for use in modifying the local
profile
>directory location to an SMB share, making you appear to have roaming 
>profiles, where instead you're just wasting bandwidth every time you
look
>at the start menu?
>
Kixtart is a scripting language that *can* edit the Registry.

On Mon, 25 Aug 1997, Jason Gerrity wrote:
> 
> >>On Tue, 26 Aug 1997, Rob Naccarato wrote:
> >
> >then, you get [user2] created, but the share [user1] still exists!
> >
> >i have only been able to reproduce the problem, not fix it: i've
sent
> >details, as best i can, to the other samba team people, so that those 
> >more familiar with smbd (where the problem lies) can fix it.  in the 
> >mean-time, i keep on hacking a local copy of smbd to see if i can
narrow
> >this down some more.
> >
> 
> So, what can I do in the meantime?  Go back to a previous version
> of Samba?  Does a previous version  stop this from happening?
no, probably not.  if it does, it's either an accident, or a bug :-)  i 
reckon that if we close the connection when the last user logs off (you 
can do several SMBsessionSetups to the same smbd) that this will solve 
the problem.

in the meantime, it's not really a problem - just avoid explicit use of 
the [homes] share - use the [user1] or [user2] share instead.

> Are there any log files I can send along to help fix
> this problem?  I concur with your observation about the smbd not
> exiting properly.
i've talked this through with jeremy - there is a background process 
responsible for logins on NT (probably WINLOGON.EXE) which maintains a 
connection to the HOMES share, even though there is no user logged on.  
this is a reasonable thing to do, except that it screws us.
>  During some tests, smbstatus showed us some
> locked files without an associated client connected.
they wouldn't happen to be user.dat or NTuser.DAT, would they?
> >> the client appears to not always make a connection to the
> >> [netlogon] share to run the logon script.  It does, however,
> >> always connect to [netlogon] to open the config.pol file, which
> >> is always run after the logon script.
> >
> >[hm.  personal question: how did you get it to open / load the
config.pol
> >file?]
> >
> 
> The trick is to set "Load Balance" on the client (in Poledit or
> in the Registry).  This setting is found in Poledit under
> Local Machine->Network->Update.  Set Update to Automatic and
> Load Balance on. Then have config.pol in the [netlogon] share,
> readable by world.  
thanks!

luke