On Tue, 18 Nov 1997, Pete Ashdown wrote:
> Doing a lsof on the file reveals:
>
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF INODE NAME
> exim 15617 root cwd VDIR 32,8 512 51072 /var/spool/mqueue/exim
> exim 15617 root txt VREG 32,30 477372 21952 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 21144 33812 /usr/lib/nss_files.so.1
> exim 15617 root txt VREG 32,30 39932 33804 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 15720 33790 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 15720 33783 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 664776 33972 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 60316 33973 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 6432 33785 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 571940 33977 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 68780 33798 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 2564 33780 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root txt VREG 32,30 137160 33771 /usr (/dev/dsk/c0t3d0s6)
> exim 15617 root 0uW VREG 32,8 660 74122 /var/spool/mqueue (/dev/dsk/c0t1d0s0)
> exim 15617 root 1r VREG 32,24 33885 8014 /etc/mail/exim/system_filter
> exim 15617 root 3w VREG 32,8 0 78801 /var/spool/mqueue (/dev/dsk/c0t1d0s0)
> exim 15617 root 4w VREG 32,8 0 68753 /var/spool/mqueue (/dev/dsk/c0t1d0s0)
> exim 15617 root 5r DOOR 0xf60259b0 (FA:->0xf5ca9980)
> exim 15617 root 6u FIFO 0xf5d8abe0 0t0 1593372 PIPE->0xf5d8ac60
>
>
> I hope someone can make sense of this. Exim's locking problems remain its
> biggest problem for me.
I'm not familiar with lsof, but three things caught my eye:
(1) There doesn't seem to be a database file on the list.
(2) I presume that the system_filter file is an Exim system filter. That
should only be in use for a very short time at the start of a delivery.
However, I have spotted a stupid bug there; Exim is forgetting to close
the system filter file after it has read it. I will fix that, of course,
but since no locking is involved I don't think it can be relevant.
(3) There is an open pipe; that suggests Exim is in the middle of doing
some local delivery (it uses a pipe to pass back data to the main
process as well as for doing actual "pipe" deliveries). Maybe something
is stuck related to the pipe? Again, this shouldn't involve any locking
of databases.
Sorry, that isn't very helpful.
--
Philip Hazel University Computing Service,
ph10@??? New Museums Site, Cambridge CB2 3QG,
P.Hazel@??? England. Phone: +44 1223 334714
--
*** Exim information can be found at
http://www.exim.org/ ***
