[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[LDM #DQQ-262777]: Problems with scour?
- Subject: [LDM #DQQ-262777]: Problems with scour?
- Date: Fri, 05 Dec 2014 14:19:58 -0700
Hi Heather,
re:
> Sorry, I guess I should have specified.
>
> The scour.sh script just runs pqactHUP and then scour:
> /usr/local/bin/ldmadmin pqactHUP
> /usr/local/bin/ldmadmin scour
Hmm... why does scour.sh do a 'ldmadmin pqactHUP'? It seems that this is not
needed as it tells all 'pqact' invocations to reread their pattern-action
files.
re:
> When I said that I ran it manually I meant that I ran this script. So the
> pcactHUP, and then the scour.
>
> I am sorry, my machine is behind a firewall so I cannot give access.
>
> I would appreciate your thoughts on this! I have never seen this happen
> before!
The most probable reason for the discrepancy between the amount of available
disk space before and after the LDM was stopped is that you have one or more
pattern-action file actions that is(are) keeping files open. The 'rm' action
that 'scour' will eventually run will appear to remove those files (meaning
that an 'ls' will not show them), but they won't really be gone. When the
LDM is stopped, all open file descriptors will be closed, and the space
being used by the open files will return to the OS.
The solution to this problem is to review your pattern-action file actions
for entries that do not close files (e.g., no '-close' flag to FILE
actions) and add a '-close'. If the problem is being caused by some sort
of site-written decoding action, you will need to figure out how to tell
that decoder to close the file.
Just so you know, _lots_ of other LDM users have run into this problem
over the years, and all have apparently solved their problem by making
sure that files get closed so that they can be reaped by scouring
actions (I say this because we have not seen an inquiry like yours
for well over 5 years and possibly 10!).
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: DQQ-262777
Department: Support LDM
Priority: Normal
Status: Closed