[Samba] gencache.tdb: device busy

[Rouven WEILER]

I added LOG statements to mutex.c printing the strerror from the return values.
 
From
 
ret = pthread_mutexattr_init(&ma); in line 570
 
I got errorno 16 --> device busy.
 
But due the manual of pthread_mutex_attr_init() there should only be ENOMEM and EINVAL...
 
Doing gdb smbd -> run
Doe not reveal anything, but I never used gdb for debugging anything. I just gave it a shot...
 
 
 
 

Gesendet: Montag, 01. April 2019 um 20:50 Uhr
Von: "Jeremy Allison" <jra at samba.org>
An: "Rouven WEILER" <Rouven_Weiler at gmx.net>
Betreff: Re: [Samba] gencache.tdb: device busy
On Mon, Apr 01, 2019 at 08:44:45PM +0200, Rouven WEILER wrote:
> I got a truss output which is the equivalent to strace on solaris as far as i got that.
> As I am not experience with strace or truss: How to I get the correct info out of it…
> I got info from this command, but do not see the pthread_XXX calls.
>
> Are there special command args I could use?
>
> Doing a "truss -f smbd > truss.out 2>&1“ came up with the output (complete output attached):
> 2116: setgroups(11, 0x011FCC40) = 0
> 2116: setregid(4294967295, 0) = 0
> 2116: getgid() = 0 [0]
> 2116: setreuid(4294967295, 0) = 0
> 2116: getuid() = 0 [0]
> 2116: umask(0) = 0
> 2116: mkdir("/var/samba/lock", 0755) Err#17 EEXIST
> 2116: umask(0) = 0
> 2116: lstat("/var/samba/lock", 0xFFFFFD7FFFDFB240) = 0
> 2116: open("/var/samba/lock/gencache.tdb", O_RDWR|O_CREAT, 0644) = 21
> 2116: fcntl(21, F_GETFD, 0x00000000) = 0
> 2116: fcntl(21, F_SETFD, 0x00000001) = 0
> 2116: fcntl(21, F_SETLKW, 0xFFFFFD7FFFDFB040) = 0
> 2116: read(21, " T D B f i l e\n\0\0\0".., 168) = 168
> 2116: fstat(21, 0xFFFFFD7FFFDFB130) = 0
> 2116: fcntl(21, F_SETLK, 0xFFFFFD7FFFDFB040) = 0
> 2116: mmap(0x00000000, 241664, PROT_READ|PROT_WRITE, MAP_SHARED, 21, 0) = 0xFFFFFD7FED194000
> 2116: lwp_mutex_register(0xFFFFFD7FED1940C8, 0xFFFFFD7FED2A30D0) = 0

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is probably what the pthread_XXX calls map to on Solaris.

You'll need to dig closer (maybe add debug statements)
to tdb_mutex_init() to see exactly which call fails.