Find sometimes returns a file name and claims: "No such file or directory"

A single-line shell command like this:
find [path] [filename pattern] -exec gzip {} \;

sometimes succeeds, and sometimes returns:
find: '[path][file_name]' No such file or directory.

How is that possible?  If the file really doesn't exist, I expect "find" to quietly do nothing.  But if it really does exists (as it does) how can bash return: "No such file or directory" and then print the exact path and file name that it claims it can't find?

We run this shell command nightly as a "host" job in OEM (Oracle Enterprise Manager) job queue on our Oracle database servers, because our management requires us to use this job scheduler, not cron or some other job scheduler.  This job always succeeds on two of the three servers we run it on, but it fails some nights, not always, on the third server.  These three servers are unrelated to each other, and have nothing in common other than they all run independent Oracle databases.

We have: Oracle Linux Server release 7.4
kernel: 4.1.12-112.14.15.el7uek.x86_64
LVL 36
Mark GeerlingsDatabase AdministratorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

slightwv (䄆 Netminder) Commented:
I've seen similar issues when other processes remove files while it is running.

I'm far from an Expert in how "find" works but from observations it expands wildcards before going into the loop.  If another process removes a file that has already been pulled into the find loop, you will see a not found message.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
what are the results of the find pattern you are running?
what is the pattern that you are searching for?

what are you compressing, log files should have their own rotation/space management.
Mark GeerlingsDatabase AdministratorAuthor Commented:
I think we found the problem.  We had two similar jobs scheduled two hours apart.  We thought that was much more than enough time for the first job to finish before the second job started, but as we're reviewing the job run times, we see that they overlapped on some nights.  Those were the nights when it reported the error.  We will re-schedule these to be farther apart.  That should prevent the possibility for one of these "find" commands to stumble over the same file the earlier job is actually working on compressing yet.
CompTIA Security+

Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.

if it takes this long, to process, a possible alternative is to get a portion of the results per run.
or run it on a more frequent basis to process fewer files at a time.
Mark GeerlingsDatabase AdministratorAuthor Commented:
These aren't log files.  These are Oracle export files produced nightly by an Oracle job.  These provide an alternate way to back up an Oracle database and a much easier way to recover individual database objects (tables, indexes, procedures, views, etc.) than trying to use an Oracle backup to recover an individual database object.
We could consider using logrotate to manage the compression of these files that are a day old.  But controlling the exact time for logrotate to process files that are produced nightly is not something that I've learned how to do precisely.  The time of the nightly export (and the manual compression step that we are doing now) is easy to control precisely in our Oracle job scheduler (OEM).
We want the latest export to always be available uncompressed, in case we need to recover something quickly.
IN your scheduler, instead of running a find and compress,
Run a processing script
That has a time limit on the run,
I.e. If you have a two hour window, the script has an hour and a half to compete.
Then it exits and the second process will process the ...

Gzip -cd <compressedfile streams the data without the need to consume space on the file system.

Another option is to use tail,head to capture a set of .

The run time scenario, I.e. Running only in off hours, etc...

If the resources are there to send the compression into the background
I.e. Compress three at a time, sending them into the background, the imaoct is on the storage system.
Mark GeerlingsDatabase AdministratorAuthor Commented:
I'm not sure what this means:
"Gzip -cd <compressedfile streams the data without the need to consume space on the file system."

The resulting compressed file will be written to the file system anyway, correct?  That is where we want it, for at least a week or so.  Then we purge the oldest one.

Are you saying that gzip uses some temporary working space on disk that can be avoided if we use certain options for gzip?
gzip -cd < deals with unpacking an compressed file without the need the space
gzip -cd < compressed.gz and on standard input outputs the data stream.

How often have you ran into a situation that you had to access the backup?

My suggestion it the opposite, compress all files, and only when needed use the gzip -cd < compressedfile to decompress and provide the data stream to the command you need ....
slightwv (䄆 Netminder) Commented:
arnold, I think you might find that not compressing the most recent is to make sure the latest objects can be recovered with the fastest possible time.  Uncompressing to stdout to pipe to import will take that much more time.  You still have the race condition of when to start compression.  Decompressing really isn't the problem, well, other than the time.

Back to the issue:  Many a child has been born because of the timing method.

Can you not combine the job into a single task that compresses/archives previous runs then exports the current one?

or find -mtime 1 [path] [filename pattern] -exec gzip {} \;

or place dates in the exports to know what to compress?

or manually fire logrotate after the export?

Sure beats a race condition...
Still trying to figure out the scope of the issue that a two hour window is not sufficient.

realize that it is faster, but the question on whether in the recent past there was a need to restore, or this is merely a precaution.

Depending on the environment, maturity on whether another approach should be made.
Mark GeerlingsDatabase AdministratorAuthor Commented:
"Can you not combine the job into a single task that compresses/archives previous runs then exports the current one?'
That is exactly what I had originally, but somehow it sometimes failed to compress the previous runs (maybe because I had the age limit set too high on the files it should compress first - then if the previous day's run was ever later than expected, by the following day, those files were not 23 hours old yet).

So, I thought I could set up a separate job to just do the file compression of the previous day's export.  But, I didn't remove the "find ...gzip" command from the main job.  That led to the occasional problem of "find ... no such file" when these job run times overlapped a bit.

And no, I don't want to compress the files immediately after the export, because I want the most recent export to be available uncompressed if I need to recover an object from it.  Sometimes the problem is not noticed until two or three days later, so having some older compressed exports still available, if necessary, is handy.
how many files are generated on a daily basis?

Running this once an hour for items older than 24 hours, after you make sure that.
This way you can distribute the load through out the day, reduce the number of files compressed in any one session.

It seems you identified the cause of the error. by separating the compression from the export/archive....
Mark GeerlingsDatabase AdministratorAuthor Commented:
There are about 20 of these large export files created every day, one from each significant schema in 10 separate, pluggable databases in an Oracle12 RAC system that we have.  The export jobs are all scheduled to run between 3-5am each morning.

Yes, I have identified the cause of the error (overlapping job runs, and job run times slower than expected).

This issue is resolved here now (by scheduling the compress job to start three hours before export job, and by adjusting the age limit on the "find ...gzip" command that is still in the export job so it handles previous files correctly, even if the job runs later than usual on some days).
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.