[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: malformed i-node-names at "TRANSPORT" directory ...

 I still getting the error with last cvs version...  But here under Linux redhat
 6.2 scheduler core dumped after such error.... It's happens always in 
 malloc functions.
 With recent version  this happens more often  when with 2.99.53-pre1


lockverify: Lock with PID=31231 is active on 444157-1062:    smtp 163.net dysygz@163.net 99
lockverify: Lock with PID=31154 is active on 441960-1061:    smtp krasu.ru gricacueva@krasu.ru 99
scheduler: unlink(../queue/B/pm@pm@)[sch-unctl-2]: No such file or directory 
 Core dump here..

arranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `scheduler -l /var/log/mail/scheduler.perflog -S -H'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /lib/libnss_dns.so.2...done.
#0  0x40081709 in chunk_alloc (ar_ptr=0x40116d60, nb=16) at malloc.c:2763
2763    malloc.c: No such file or directory.
(gdb) bt
#0  0x40081709 in chunk_alloc (ar_ptr=0x40116d60, nb=16) at malloc.c:2763
#1  0x400815ce in __libc_malloc (bytes=5) at malloc.c:2696
#2  0x8062c70 in emalloc ()
#3  0x8061d1f in strnsave ()
#4  0x8061d78 in strsave ()
#5  0x804dfd1 in vtxprep ()
#6  0x804c95a in schedule ()
#7  0x804c144 in syncweb ()
#8  0x804b412 in main ()
#9  0x400409cb in __libc_start_main (main=0x804a62c <main>, argc=5,
    argv=0xbffffe34, init=0x804987c <_init>, fini=0x807c8dc <_fini>,
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffe2c)
    at ../sysdeps/generic/libc-start.c:92
(gdb) q 

  you wrote:
> On Fri, Sep 01, 2000 at 01:24:28PM +0200, Arnt Gulbrandsen wrote:
> > Matti Aarnio <mea@nic.funet.fi>
> > >   However I don't know any LOCAL filesystems which exhibit this behaviour,
> > >   and I do believe that even NFS is sane in this regard.
> > >   Any other possibilities ? Anyone ?
> ....
> >> rename() and stat() can go wrong IRC, of course, and need result
> > checking.  The link()/unlink() pair aren't ever going to be tested,
> > I'd guess, so keep it simple.
> > 
> > (Do I even understand the problem correctly?)
> 	Maybe, close to.
> 	I just would like to minimize directory access syscalls to
> 	POSTOFFICE/ filepaths, which means  stat()  is no good,
> 	fstat() is better (open filehandle, and all that).
> 	Do keep in mind that all this is hearsay from comments that
> 	exist at zmailer 2.2.1 libc/mail.c  (yes, THAT old..)
> 	Therefore I would like to know if there really exists such
> 	monsters, and how come  rename()  won't preserve i-node
> 	while link()/unlink() will ?
> 	I can imagine many filesystems at which link()/unlink() won't
> 	work, and where the i-node number depends on where on the disk
> 	the directory entry for it is located at so that it changes at
> 	every rename() when e.g. BTREE is reorganized or file is moved
> 	from one storage partition (server) to another.  But then such
> 	systems are NOT suitable for POSTOFFICE to begin with..
> 	(AFS, CODA, possibly MS NTFS to name a few.)
> 	... I take that back a bit.  The message submission is the only
> 	phase in the system which makes such file systems unsuitable.
> 	Latter router and scheduler will preserve the numeric string
> 	representing the unique file identity.
> 	(Performance may also be bad - at least at AFS and CODA for
> 	 POSTOFFICE like operations, but that is irrelevant here.)
> 	For message submission some method could be found that creates
> 	unique numeric strings (possibly recurring, like i-node numbers,
> 	but unique for the message lifetime) in some platform specific way.
> 	Current one assumes certain class of UNIX local filesystems.
> 	What *must* be guaranteed is that the same name won't recur
> 	while the message is in processing, although not in any of
> 	$POSTOFFICE/router*/ dirs.
> 	System needs more work if the basic rule of "work files are
> 	named with all decimal number characters" should be relaxed.
> >  --Arnt
> -- 
> /Matti Aarnio	<mea@nic.funet.fi>