On Wed, Oct 31, 2007 at 01:05:38PM -0700, Stephen Hahn wrote: > * Nicolas Williams <Nicolas.Williams at sun.com> [2007-10-31 19:41]: > > On Wed, Oct 31, 2007 at 11:42:34AM -0700, Stephen Hahn wrote: > > > Just so I understand, why isn't restart_on="refresh" sufficient? > > > (It's how the milestone/name-service dependency some services have is > > > handled, and seems to be similar on first glance.) > > > > Because restarting the svc:/network/smb/server service would reset > > client connections, which the i-team considers too disruptive. These > > would be sufficiently rare events that users might not mind too much. > > So the daemon will cache sufficient credential state so that these > connections (from the previous naming discipline) will still be > operating correctly? (Enough state to also debug this situation?)
Apparently so. I'm not in that i-team, so I don't know for sure. > (I suppose a question about robustness on non-administrative restarts > is in order: does the daemon cache any state outside itself so that > it can handle actual errors without affecting the existing > connections? Could it?) Good question. The SMB service is like the NFS one: mostly it runs in kernel, with some user-land support functions. Should restarting the user-land components drop client connections for either NFS or SMB? I would think not, but I don't know why it is this way for SMB. I'll ask. > > Is it your opinion that emulating refresh_on is not worthwhile and that > > we should use restart_on until refresh_on is added? > > > > Also, do you recommend the placeholder service approach, or any others? > > I think the placeholder approach can work. I don't have a strong > opinion about refresh_on. OK, thanks.
