This morning I noticed many failures in my modis and meris processing streams. At first I thought is was just a network issue.
However, I see that it seems to be that the query server provides data that does not exist to download:

Input file : /tmp/s4p_proc_mer_l2_0.06_ADNSW4sz/M2011166163123.L1B_FRS
Start time : 2011166163123
End time   : 2011166163346

Downloading N2011166_SST_OIV2AVAM_24h.nc

*** ERROR: The HTTP transfer failed with status code 8.
...

>wget http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/N2011166_SST_OIV2AVAM_24h.nc

--2011-06-16 11:40:09--  http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/N2011166_SST_OIV2AVAM_24h.nc
Resolving oceandata.sci.gsfc.nasa.gov (oceandata.sci.gsfc.nasa.gov)... 169.154.128.84
Connecting to oceandata.sci.gsfc.nasa.gov (oceandata.sci.gsfc.nasa.gov)|169.154.128.84|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2011-06-16 11:40:11 ERROR 404: Not Found.

Apparently data showing in subscriptions has the same issue. I download automatically every 1/2 hour files showing up there.
This is happening when I check the file:

file /optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2
/optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2: ASCII English text

cat /optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2
Apparently, the file you seek is not available.

Sorry.

rm /optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2

curl --output /optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2 http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/MOD00.P2011167.1625_1.PDS.bz2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0    57    0    57    0     0     26      0 --:--:--  0:00:02 --:--:--    53

file /optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2
/optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2: ASCII English text

cat /optics1/scratch/data/roi/l0/2011/167/MOD00.P2011167.1625_1.PDS.bz2
Apparently, the file you seek is not available.

Sorry.

I get a similar error.

modis_atteph.py ./A2011167130500.L1A_LAC
The server couldn't fulfill the request.
Error code:  404
*** ERROR: The HTTP transfer failed with status code 404.
*** Please check your network connection and for the existence of the remote file:
*** http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/PM1ATTNR_NRT.A2011167.1305.005
***

That URL returns the same message:

Apparently, the file you seek is not available.

Sorry.

I had the errors last night in L2 as well:

STATUS: $anc_script = /optics1/software/seadas/seadas_6.2.2a/run/scripts/getanc /tmp/s4p_proc_l2_roi_0.04_0uAMWCq3/MYD021KM.2011167.1645.BOHAI.hdf
STATUS: $anc_script_return = Determining pass start and end times..

Input file : /tmp/s4p_proc_l2_roi_0.04_0uAMWCq3/MYD021KM.2011167.1645.BOHAI.hdf
Start time : 2011167164500
End time   : 2011167165449

Downloading S201116712_NCEP.MET

*** ERROR: The HTTP transfer failed with status code 8.
*** Please check your network connection and for the existence of the remote file:
*** http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S201116712_NCEP.MET
***
*** Also check to make sure you have write permissions under the directory:
*** /optics1/software/seadas/seadas_6.1/var/anc/
***
*** If you cannot obtain write permissions here you can set up your own ancillary
*** directory by copying the seadas.env_user_bash or seadas.env_user_csh file
*** into your ~/.seadas/ directory and editing the USER_L2GEN_ANC line.

Brock, Quinten,

I believe we've resolved the problem.  There were actually two issues.

    1) A large table update around 9am Eastern time yesterday caused the script that updates the file location table to get kicked out.
That left a stale lockfile in place, which I didn't notice until I saw Brock's post.  Once that was cleared up, the file location information
was brought back up to sync with the production database.

   2) This one was the head scratcher.  The web database is actually a mini cluster - with a publically accessible slave and a firewalled
master.  The problem was with the firewall - it drops idle connections - any connection idle for 300 seconds.  The master database is
updated with production every 600 seconds.  The slave DB doesn't consider a lack of chattiness from the master to be a problem for
3600 seconds.  This was producing a lag of an hour (well, could be 70 minutes) between production and the outside world.  To
complicate matters, we are transitioning to hardware/db - so the file location information is actually on two servers - the old hardware
(which gets updated more frequently because it's doing more than just file location info and thus didn't suffer from the idle connection
syndrome) is what gets queried by getanc (and the atteph equivalent for MODIS geolocation).  It knew about files that the newer
hardware was ignorant of - at least for about an hour.  So, when you run the script looking for new data, you'd encounter a problem.

That's the long story.  The short story - Fixed.

Sorry for the woes, and thanks for your patience.
Don't hesitate to let us know if things don't go back to normal at your end.

Sean

Thanks for all you do!

Brock

Hi Sean,

Big thanks for your support!

I appreciate your effort for giving us the long story.

Quinten

Sean,

I'm experiencing a problem that may be related to the earlier one posted by Brock.  I use "file_search.cgi" in combination with wget to download ancillary meteorological data (e.g. S201116318_NCEP.MET):

usr/bin/wget  -q --post-data="dtype=MET&addurl=1&results_as_file=1&search=S${year}${day}*" -O - http://oceandata.sci.gsfc.nasa.gov/cgi/file_search.cgi | /usr/bin/wget -N -i -

This was working fine until June 13 2011- after that it couldn't find the files anymore even though they existed.  I was using "dtype=MET" as one of the parameters passed to file_search.cgi.  I discovered that if I remove this condition, it finds the files.  Similarly, when using the File Search webpage on the oceancolor website (http://oceandata.sci.gsfc.nasa.gov/cgi/file_search.cgi), the MET files are only found if "All Types" is selected rather than "Ancillary".  Now that I've figured it out it's no longer a problem for me, but I wanted to point it out in case the change was unintentional.

Thanks!
Jasmine.

Jasmine,

The change was intentional, although should have been transparent to the user - unfortunately, I failed to update file_search.cgi to set dtype=anc when ancillary met data were selected...
The fix is now in.

Thanks for pointing out the oversight.
Sean