[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990303: Scouring McIDAS XCD data files (cont.)

>From: "Gen. McIDAS" <address@hidden>
>Organization: UVa
>Keywords: 199903022316.QAA06783 McIDAS LDM scour

Jennie,

>Actually, I want to correct something I said above...I did not
>uncomment the line in cron, it was theoretically running, however,
>when the scour.conf file had been setup, the directory for the
>incoming data was prepended with a ~, which made it point to
>a directory that doesn't exist.  But, I edited the scour.conf
>file to make it look at the right directories, and *then* I ran
>it by hand (ldmadmin scour).  I realized after reading your
>message last night that the scour entry was still in cron (a command to
>run ldmadmin scour), but....for reasons I still don't understand,
>this cron entry was not actually doing anything ?

I can't explain this without looking further into your setup.

>I edited the scour.conf file to comment out the scouring and I will
>remove the ldmadmin scour  entry from cron, but I don't understand
>why it didn't run anyway?

You may want to keep running LDM's scour for non-McIDAS data (that is, data
in non-McIDAS directories).  To scour McIDAS data files (GRID, MDXX, and
TEXT), it is best to use McIDAS commands like the ones in mcscour.sh.

>So I should edit both cron jobs today and move the mcscour.sh  command
>(/home/mcidas/bin/mcscour.sh, which currently runs at 20:55) to the mcidas 
>account.

Since moving the scouring from the LDM account to McIDAS is quick and easy,
this would be the first thing that I would do.  The objective, of course,
is to get a setup where scouring works and requires little/no attendance.

>Hmmm, glad someone remembers whats up with our system :-(.  Look, I do recall
>we have had difficulties before, but the scouring had been working, and then
>it stopped.

This is what I don't understand.  Software should continue to work unless
something else changes.  The question is what was changed (and where)
to cause the scouring to stop working)?

>I am pretty sure that I looked at the scour log file and it was
>old, this only told me that that mscour.sh wasn't running (which was pretty
>obvious)....and I didn't know why, but I needed to make space because the 
>disk was full....

I understand completely.  When the disk fills up, drastic measures are
called for.

>Well, I know that for some things in cron we use the /usr/bin/rm rather
>than just rm, and this seems to override our aliasing of the command rm
>(does this make sense?)

Yes, running the command with a fully qualified pathname circumvents
the alias mechanism.

>But, I don't see were rm commands are being
>invoked anyway?

The McIDAS command DELWXT runs 'rm -f'.  Chiz speculated that it might
inherit the alias (rm <-> rm -i) which would require manual response
to complete (yes or no).  I must say that I never alias rm, but I know
that a number of users do.  Thinking about how people do things here,
I can say that, for the most part, people create a new command name
when they alias something (like 'll' for 'ls -l', etc.).  This way the
"real" command is always available.

>We do have a few errors in the mcscour log, for having
>set up a couple of commands with bad syntax (using lwu.k DELETE rather
>than lwu.k DEL....but the error was for old VIRT files that we don't 
>even use anymore).

OK, this shouldn't harm anything.

re: keeping an eye on scouring to find out why it stops working
>Right. 
>Thanks Tom! I appreciate your willingness to just fix it since I was home and 
>probably wouldn't done it from home last night, our University modem links 
>are pretty unreliable and you can get thrown off in the middle of important
>things.

No problem.

You wouldn't believe how consumed I have been for the past several weeks
with getting a machine ready to take home so I can work from home.  I don't
know if you caught the comment sent to the Usercomm (by Linda?) that Unidata
will be forced out of its offices for a two week period starting around
the time of the next meeting.  During this time, we can either take vacation
(who wants to take vacation mandated by someone else?); get a machine setup
somewhere temporarily (like the converence room (gag)); or work from home.
I guess you know that most people want to work from home (big suprise).

Got to get back to 7.5 documentation.  Talk to you later...

Tom

>From address@hidden  Wed Mar  3 12:15:54 1999
 
re: can't explain without further looking around
>Well, you can look but I recognize its a matter of time and
>priority, this isn't a high priority (as long as mcscour.sh
>is working).

re: changing scouring from the LDM account to the McIDAS account
>Okay, will do...can't say I see the difference between user mcidas and
>user ldma, but I'll switch it around.

re: trying to figure out what was going on
>I *did try* to think about what might have happened, but I really cannot
>say.  Around the time the scouring was failing, I was trying to clean-up 
>some space on the user portion of the disk and I decided we didn't need the 
>mcidas7.1 stuff around any longer, so I was wiping a lot of that out.  My 
>first thought was that I might have clobbered things if we had been running 
>an old version of mcscour.sh, I really thought this might have been it.....
>but it wasn't.  I also thought if someone had accidentally changed the 
>default redirections for user mcidas this could have screwed things up, 
>but it was fine when I checked it, and anyway that should have shown up
>as other problems (our satellite routines continued to run operationally, well
>until the disk was full....)

re: aliasing 'rm'
>Well, with rm, it would still mean you could accidently type rm....
>some of us need to be protected from ourselves more than others I guess.