Re: Change Notification
On Tue, Jan 14, 2003 at 07:49:48AM +0100, Juergen Hasch wrote: > [EMAIL PROTECTED] wrote: > > >So if I'm understanding you correctly this is actually a kernel > >bug - correct ? > > > >Can you point me at the areas in the kernel source where the problem > >occurs so I can see how to make smbd work around it until we get the > >kernel fixed. > > > > > > > No it's Samba receiving a signal from the kernel, but not processing it > further inside Samba. > > In notify_kernel/signal_handler() signals_received gets increased when a > change notification > is received from the kernel. Now the change notification for this type > of event (e.g. copy/ > rename/delete...) needs to be processed inside Samba. > This is done in process_pending_change_notify_queue() which is called > from a few places > inside e.g. reply.c. > This is not happening for file copy in my test setup here (using the > copy command in windows). > This means the kernel change notification is no longer active for this > type of event, because it > needs to be restarted in notify_kernel.c/kernel_register_notify(). > > Eventually process_pending_change_notify_queue() is called by chance and > the received > change notification signal gets processed at a later random time. Well it's not called 'by chance'. It's called once smbd gets back to the main loop should notice in the next select that a changenotify has occurred (the select should return -1, errno == EINTR and then the function async_processing() should be called before the next smbd is processed. Can you send me a debug level 10 please of the operation failing, plus an *exact* method of duplicating it (client OS, smb.condf, exact client windows open and what you do to reproduce it). Thanks, Jeremy.
Re: Change Notification
[EMAIL PROTECTED] wrote: So if I'm understanding you correctly this is actually a kernel bug - correct ? Can you point me at the areas in the kernel source where the problem occurs so I can see how to make smbd work around it until we get the kernel fixed. No it's Samba receiving a signal from the kernel, but not processing it further inside Samba. In notify_kernel/signal_handler() signals_received gets increased when a change notification is received from the kernel. Now the change notification for this type of event (e.g. copy/ rename/delete...) needs to be processed inside Samba. This is done in process_pending_change_notify_queue() which is called from a few places inside e.g. reply.c. This is not happening for file copy in my test setup here (using the copy command in windows). This means the kernel change notification is no longer active for this type of event, because it needs to be restarted in notify_kernel.c/kernel_register_notify(). Eventually process_pending_change_notify_queue() is called by chance and the received change notification signal gets processed at a later random time. So I think Samba forgets to call process_pending_change_notify_queue() after a copy operation, so a Windows application waiting for a change notification doesn't get noticed or only after some time when other file operations triggered the process_pending_change_notify_queue() call. ...Juergen
Re: Change Notification
On Mon, Jan 13, 2003 at 11:39:27PM +0100, Juergen Hasch wrote: > > > > > >Can you give me more details please about where smbd is missing > >the signal ? smbd should not be able to miss these signals, as > >all they do is set a flag that is then processed inline in the > >main loop. > > > >Please give me more details asap. > > > For testing I have a simple windows program to activates change > notification for a given directory on > the Samba side. I can then see what is happening when I copy, remove or > delete files (this is > what I tested). The Samba server is Suse 8.1 with the latest 2.4 kernel > and Samba 2_2 CVS, > my client is a W2K WS. > > When I check the signal_handler() function in notify_kernel.c I can see, > that after starting a new > smbd I get a signal when I copy/move/delete a file. For copy this > happens only once, for > rename/delete signal_handler is called every time. > When I check the kernel_remove_notify() / kernel_register_notify() > functions which have to be > called every time after a signal is received, they only get called for > move or delete operations. So if I'm understanding you correctly this is actually a kernel bug - correct ? Can you point me at the areas in the kernel source where the problem occurs so I can see how to make smbd work around it until we get the kernel fixed. Jeremy.
Re: Change Notification
Below is my test program, nothing special:
/* test change notification */
#include
#include
int main()
{
DWORD dwWaitStatus;
HANDLE dwChangeHandles[1];
dwChangeHandles[0] = FindFirstChangeNotification(
"i:\\TEST", // directory to watch
FALSE, // do not watch the subtree
FILE_NOTIFY_CHANGE_FILE_NAME); // watch file name changes
if (dwChangeHandles[0] == INVALID_HANDLE_VALUE)
exit(GetLastError());
printf("Starting change notification\n");
// Change notification is set. Now wait on both notification
// handles and refresh accordingly.
while (TRUE) {
dwWaitStatus = WaitForMultipleObjects(1, dwChangeHandles,
FALSE, INFINITE);
printf(".");
switch (dwWaitStatus) {
case WAIT_OBJECT_0:
if (FindNextChangeNotification( dwChangeHandles[0]) ==
FALSE )
exit(GetLastError());
break;
default:
printf( "Change notify failure\n");
exit(0);
break;
}
}
return 0;
}
I can't tell you if the change I made to reply.c completely solves my
problem , I'll need to test this at work.
But what I found out would explain the effects I had.
...Juergen
Re: Change Notification
Can you give me more details please about where smbd is missing the signal ? smbd should not be able to miss these signals, as all they do is set a flag that is then processed inline in the main loop. Please give me more details asap. For testing I have a simple windows program to activates change notification for a given directory on the Samba side. I can then see what is happening when I copy, remove or delete files (this is what I tested). The Samba server is Suse 8.1 with the latest 2.4 kernel and Samba 2_2 CVS, my client is a W2K WS. When I check the signal_handler() function in notify_kernel.c I can see, that after starting a new smbd I get a signal when I copy/move/delete a file. For copy this happens only once, for rename/delete signal_handler is called every time. When I check the kernel_remove_notify() / kernel_register_notify() functions which have to be called every time after a signal is received, they only get called for move or delete operations. As I understand the code the actual change notification processing is initiated by the process_pending_change_notify_queue() function. This function doesn't get called when I copy a file to the directory with change notification activated. For rename or delete this works. ...Juergen
Re: Change Notification
On Mon, Jan 13, 2003 at 11:06:46PM +0100, Juergen Hasch wrote: > Jeremy, > > I'm having problems with change notification in Samba 2.2.x under Linux > since you changed the signal > handling stuff some time ago. > An application I'm using always complains about missing change > notification, although it used to work. > I always failed to find out what's wrong, but now I know :-) > > What is happening is that Samba receives a change notification signal > from the Linux kernel and sometimes > simply does not process it, which means that no further signals will be > send by the Kernel (DN_MULTISHOT isn't set) > for the same event. > Processing of the received signal happens for file rename and delete in > but not for copying. > In reply.c/reply_write_and_X() I added a call to > process_pending_change_notify_queue((time_t)0); > and now change notification works again for my testcase here. > > I'm sure you now a better place where > process_pending_change_notify_queue() should go to catch > file copy events :-) Can you give me more details please about where smbd is missing the signal ? smbd should not be able to miss these signals, as all they do is set a flag that is then processed inline in the main loop. Please give me more details asap. Thanks, Jeremy.
