Dear Users,
I find that after live migrating a container samba refuses to accept
new connections (existing connections continue to work properly). I
traced it back to this message in the logs which says "
tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has
changed!" . Of course the inode changed, but does it need to panic...
Is there a workaround?

I'd be willing to bet someone has come across this before, but I
couldn't find an answer on the wiki or the list archives.

Centos 5
samba-3.0.25b-1.el5_1.4
vzctl-3.0.18-1
Thanks,
             jeff

[2008/01/22 11:53:46, 0] lib/util_tdb.c:tdb_log(662)
  tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has changed!
[2008/01/22 11:53:46, 0] smbd/server.c:open_sockets_smbd(572)
  tdb_reopen_all failed.
[2008/01/22 11:53:46, 0] lib/util.c:smb_panic(1654)
  PANIC (pid 22099): tdb_reopen_all failed.
[2008/01/22 11:53:46, 0] lib/util.c:log_stack_trace(1758)
  BACKTRACE: 6 stack frames:
   #0 smbd(log_stack_trace+0x1c) [0x555555776ffc]
   #1 smbd(smb_panic+0x43) [0x5555557770e3]
   #2 smbd [0x55555582ac3a]
   #3 smbd(main+0x710) [0x55555582b370]
   #4 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aaaad3818a4]
   #5 smbd [0x5555555bbfe9]
[2008/01/22 11:53:46, 0] lib/fault.c:dump_core(181)
  dumping core in /var/log/samba/cores/smbd


-- 
Jeff Blasius / jeff.blasius@yale.edu
Phone: (203)432-9940  51 Prospect Rm. 011
High Performance Computing (HPC)
UNIX Systems Administrator, Linux Systems Design & Support (LSDS)
Yale University Information Technology Services (ITS)

Looks like samba tries to be too smart :/
The only thing which can help to it - clustered file system like GFS which won't change inode numbers
across nodes... As another option - VE in a file (via loopbacks) which we plan to implement in nearest future.

Thanks,
Kirill


Jeff Blasius wrote:
> Dear Users,
> I find that after live migrating a container samba refuses to accept
> new connections (existing connections continue to work properly). I
> traced it back to this message in the logs which says "
> tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has
> changed!" . Of course the inode changed, but does it need to panic...
> Is there a workaround?
> 
> I'd be willing to bet someone has come across this before, but I
> couldn't find an answer on the wiki or the list archives.
> 
> Centos 5
> samba-3.0.25b-1.el5_1.4
> vzctl-3.0.18-1
> Thanks,
>              jeff
> 
> [2008/01/22 11:53:46, 0] lib/util_tdb.c:tdb_log(662)
>   tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has changed!
> [2008/01/22 11:53:46, 0] smbd/server.c:open_sockets_smbd(572)
>   tdb_reopen_all failed.
> [2008/01/22 11:53:46, 0] lib/util.c:smb_panic(1654)
>   PANIC (pid 22099): tdb_reopen_all failed.
> [2008/01/22 11:53:46, 0] lib/util.c:log_stack_trace(1758)
>   BACKTRACE: 6 stack frames:
>    #0 smbd(log_stack_trace+0x1c) [0x555555776ffc]
>    #1 smbd(smb_panic+0x43) [0x5555557770e3]
>    #2 smbd [0x55555582ac3a]
>    #3 smbd(main+0x710) [0x55555582b370]
>    #4 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aaaad3818a4]
>    #5 smbd [0x5555555bbfe9]
> [2008/01/22 11:53:46, 0] lib/fault.c:dump_core(181)
>   dumping core in /var/log/samba/cores/smbd
> 
>

Hello Kirill,
Thanks for the response. This must be windows fault in some way :).

I will see if there's a way around it from the samba folks. If I get
anything constructive I'll report it back here.
     -jeff

On Jan 23, 2008 4:33 AM, Kirill Korotaev <dev@sw.ru> wrote:
> Looks like samba tries to be too smart :/
> The only thing which can help to it - clustered file system like GFS which won't change inode numbers
> across nodes... As another option - VE in a file (via loopbacks) which we plan to implement in nearest future.
>
> Thanks,
> Kirill
>
>
>
> Jeff Blasius wrote:
> > Dear Users,
> > I find that after live migrating a container samba refuses to accept
> > new connections (existing connections continue to work properly). I
> > traced it back to this message in the logs which says "
> > tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has
> > changed!" . Of course the inode changed, but does it need to panic...
> > Is there a workaround?
> >
> > I'd be willing to bet someone has come across this before, but I
> > couldn't find an answer on the wiki or the list archives.
> >
> > Centos 5
> > samba-3.0.25b-1.el5_1.4
> > vzctl-3.0.18-1
> > Thanks,
> >              jeff
> >
> > [2008/01/22 11:53:46, 0] lib/util_tdb.c:tdb_log(662)
> >   tdb(/var/cache/samba/ntforms.tdb): tdb_reopen: file dev/inode has changed!
> > [2008/01/22 11:53:46, 0] smbd/server.c:open_sockets_smbd(572)
> >   tdb_reopen_all failed.
> > [2008/01/22 11:53:46, 0] lib/util.c:smb_panic(1654)
> >   PANIC (pid 22099): tdb_reopen_all failed.
> > [2008/01/22 11:53:46, 0] lib/util.c:log_stack_trace(1758)
> >   BACKTRACE: 6 stack frames:
> >    #0 smbd(log_stack_trace+0x1c) [0x555555776ffc]
> >    #1 smbd(smb_panic+0x43) [0x5555557770e3]
> >    #2 smbd [0x55555582ac3a]
> >    #3 smbd(main+0x710) [0x55555582b370]
> >    #4 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aaaad3818a4]
> >    #5 smbd [0x5555555bbfe9]
> > [2008/01/22 11:53:46, 0] lib/fault.c:dump_core(181)
> >   dumping core in /var/log/samba/cores/smbd
> >
> >
>



-- 
Jeff Blasius / jeff.blasius@yale.edu
Phone: (203)432-9940  51 Prospect Rm. 011
High Performance Computing (HPC)
UNIX Systems Administrator, Linux Systems Design & Support (LSDS)
Yale University Information Technology Services (ITS)

> won't change inode numbers across nodes... As another option 
> - VE in a file (via loopbacks) which we plan to implement in 
> nearest future.

VE in a file sounds interesting - what is the reasoning about that
(advantages, usage scenarios)?

- Dietmar