On Mon, 2006-05-29 at 08:47 +1000, James Peach wrote:
On 5/29/06, Volker Lendecke [EMAIL PROTECTED] wrote:
On Sun, May 28, 2006 at 08:34:57PM +0200, Thomas Bork wrote:
Please accept this patch for configure.in, removing the function
introduced in 15508 (Use clock_gettime for profiling
On Mon, 2006-05-29 at 09:34 +1000, James Peach wrote:
On Mon, 2006-05-29 at 08:47 +1000, James Peach wrote:
On 5/29/06, Volker Lendecke [EMAIL PROTECTED] wrote:
On Sun, May 28, 2006 at 08:34:57PM +0200, Thomas Bork wrote:
Please accept this patch for configure.in, removing the function
Volker Lendecke wrote:
[2006/05/25 15:25:42, 0] smbd/oplock_linux.c:linux_init_kernel_oplocks(247)
Failed to setup RT_SIGNAL_LEASE handler
[2006/05/25 15:25:42, 0] smbd/notify_kernel.c:kernel_notify_init(224)
Failed to setup RT_SIGNAL_NOTIFY handler
Is this a change from pre1? I'm not
On Sun, May 28, 2006 at 08:34:57PM +0200, Thomas Bork wrote:
Please accept this patch for configure.in, removing the function
introduced in 15508 (Use clock_gettime for profiling timestamps if it is
available. Use the fastest clock available on uniprocessors.):
Hmmm. Fully removing it might
On Sun, May 28, 2006 at 09:38:27PM +0200, Volker Lendecke wrote:
On Sun, May 28, 2006 at 08:34:57PM +0200, Thomas Bork wrote:
Please accept this patch for configure.in, removing the function
introduced in 15508 (Use clock_gettime for profiling timestamps if it is
available. Use the
On 5/29/06, Volker Lendecke [EMAIL PROTECTED] wrote:
On Sun, May 28, 2006 at 08:34:57PM +0200, Thomas Bork wrote:
Please accept this patch for configure.in, removing the function
introduced in 15508 (Use clock_gettime for profiling timestamps if it is
available. Use the fastest clock
On Mon, May 29, 2006 at 11:54:43AM +1000, James Peach wrote:
Unfortunately, I think that this means that we need a new configure
macro to test whether linking with librt implicitly links libpthread. If
it does, we can disable clock_gettime without disabling
--with-profiling-data.
This
On Thu, May 25, 2006 at 03:31:07PM +0200, Thomas Bork wrote:
[2006/05/25 15:25:42, 0] smbd/oplock_linux.c:linux_init_kernel_oplocks(247)
Failed to setup RT_SIGNAL_LEASE handler
[2006/05/25 15:25:42, 0] smbd/notify_kernel.c:kernel_notify_init(224)
Failed to setup RT_SIGNAL_NOTIFY handler
On Thu, May 25, 2006 at 05:50:27PM +0200, Thomas Bork wrote:
Switched back to 3.0.21c. Ouch, access to shares is not granted anymore :(
Are you using tdbsam? I think we upgrade passdb.tdb's
version.
Volker
pgpj2aHkCk1wY.pgp
Description: PGP signature
--
To unsubscribe from this list go to
Volker Lendecke wrote:
Switched back to 3.0.21c. Ouch, access to shares is not granted anymore :(
Are you using tdbsam? I think we upgrade passdb.tdb's
version.
No, using smbpasswd.
I don't understand the error message on the client. Samba isn't a domain
controller at this time.
der tom
Hi @all,
I have many messages in the log file with this version:
[2006/05/25 15:25:42, 0] smbd/oplock_linux.c:linux_init_kernel_oplocks(247)
Failed to setup RT_SIGNAL_LEASE handler
[2006/05/25 15:25:42, 0] smbd/notify_kernel.c:kernel_notify_init(224)
Failed to setup RT_SIGNAL_NOTIFY handler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Bork wrote:
Hi @all,
I have many messages in the log file with this version:
[2006/05/25 15:25:42, 0] smbd/oplock_linux.c:linux_init_kernel_oplocks(247)
Failed to setup RT_SIGNAL_LEASE handler
[2006/05/25 15:25:42, 0]
Gerald (Jerry) Carter wrote:
Volker, I don't know of any outstanding issues with
kernel oplocks. Any ideas?
Volker, before you are asking:
No kernel changes, no changes to the operating system, no changes to the
configure options, no changes to the developer tools since a long time...
Thomas Bork wrote:
[2006/05/25 15:25:42, 0] smbd/oplock_linux.c:linux_init_kernel_oplocks(247)
Failed to setup RT_SIGNAL_LEASE handler
Switched back to 3.0.21c. Ouch, access to shares is not granted anymore :(
The client is confused and thinks the samba server is an domain controller!:
14 matches
Mail list logo