Sponsored Content
Top Forums Shell Programming and Scripting Strange behavior of find and rm command Post 302943791 by Don Cragun on Tuesday 12th of May 2015 10:21:51 PM
Old 05-12-2015
Nothing says that the other process that removed, moved, or deleted that file was being run by another find command nor that it had been started by cron. Anybody logged on to your network with write access to the directory in question could remove a file. And, by the time you see the error message, that process could already be gone. There might not be a running process left to find. If you have process accounting running, you might be able to find who was running another process at the time find reported the error.

Of course if you were running the two copies of the same script at the same time, you could easily see several errors like that as they fight with each other trying to be the first one to find and process the selected files. But, if you have only seen this once, it is more likely that someone manually removed a file while your cron job was running.
 

9 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

strange behavior of find with xargs

Help me understand the right output. We have two machines. The first one is HP-UX machine1 B.11.00 U 9000/800 694339343 unlimited-user license The second one is AIX machine2 2 5 00067B2F4C00 with AIX version 5.2.0.0 Here is the command that I use on both systems on different... (9 Replies)
Discussion started by: jerardfjay
9 Replies

2. Programming

Strange behavior in C++

I have the following program: int main(int argc, char** argv){ unsigned long int mean=0; for(int i=1;i<10;i++){ mean+=poisson(12); cout<<mean<<endl; } cout<<"Sum of poisson: "<< mean; return 0; } when I run it, I get the... (4 Replies)
Discussion started by: santiagorf
4 Replies

3. Ubuntu

Ubuntu strange behavior

It is so till login screen. I mean that when I boot my computer, Ubuntu shows a splash screen with mouse instead of Ubuntu logo and in the login screen it shows XUbuntu login screen... It began when I upgraded to previous kernel, I suppose, but I'm not sure... I can't say that it annoys me very... (6 Replies)
Discussion started by: Sapfeer
6 Replies

4. AIX

Strange memory behavior

Hello together, i have a strange memory behavior on a AIX 7.1 System, which i cannot explain. The Filesystem-Cache will not be grow up and drops often after few minutes. I know if a file was deleted, that the same segment in the FS-Cache will also be cleared. But i am not sure if this is the... (8 Replies)
Discussion started by: -=XrAy=-
8 Replies

5. UNIX for Advanced & Expert Users

Behavior of Find command

Centos 5.8 Lets say I have 2 nfs shares mounted to /folder1 and /folder2. If I do a find / -name *something* Will it also search the 2 nfs shares ? If so is there a way to avoid this? Thanks (2 Replies)
Discussion started by: whegra
2 Replies

6. AIX

Strange behavior with tar

I am trying to create an archive using tar. I am specifying a list of directories using the -L option. For testing purposes I created a simple directory structure: /backup/test /backup/test/test1 /backup/test/test2 The file specified by the -L option, named files.txt, contains:... (8 Replies)
Discussion started by: judykstra
8 Replies

7. Shell Programming and Scripting

Strange behavior of grep

Hi All, I am facing a strange problem while grepping for a process. Here is the small script that i have written. It will look for any process running with the parameter passed to the script. If no process is running it should print appropriate message. $ cat t.ksh #!/bin/ksh set -x ... (9 Replies)
Discussion started by: veeresh_15
9 Replies

8. Shell Programming and Scripting

Strange Ctrl+C behavior

Hello All, I have a strange issue. I've created a shell script which connects to RMAN (Oracle Recovery Manager) and executes full DB backup. I then executed this script with nohup and in the background: $ nohup my_script.sh > logfile.log 2>&1 &The issue is that when I tried to take a look into... (6 Replies)
Discussion started by: JackK
6 Replies

9. UNIX for Advanced & Expert Users

Strange behavior from kill command

I am getting some strange behaviour from the kill command. When I run the which command it says it points to /usr/bin/kill. When I look at my PATH I have /usr/bin in it. So why does running kill or /usr/bin/kill produce different outputs? ghost ~ $ which kill /usr/bin/kill ghost ~ $ kill... (5 Replies)
Discussion started by: cokedude
5 Replies
queuedefs(4)                                                       File Formats                                                       queuedefs(4)

NAME
queuedefs - queue description file for at, batch, and cron SYNOPSIS
/etc/cron.d/queuedefs DESCRIPTION
The queuedefs file describes the characteristics of the queues managed by cron(1M). Each non-comment line in this file describes one queue. The format of the lines are as follows: q.[njobj][nicen][nwaitw] The fields in this line are: q The name of the queue. a is the default queue for jobs started by at(1); b is the default queue for jobs started by batch (see at(1)); c is the default queue for jobs run from a crontab(1) file. njob The maximum number of jobs that can be run simultaneously in that queue; if more than njob jobs are ready to run, only the first njob jobs will be run, and the others will be run as jobs that are currently running terminate. The default value is 100. nice The nice(1) value to give to all jobs in that queue that are not run with a user ID of super-user. The default value is 2. nwait The number of seconds to wait before rescheduling a job that was deferred because more than njob jobs were running in that job's queue, or because the system-wide limit of jobs executing has been reached. The default value is 60. Lines beginning with # are comments, and are ignored. EXAMPLES
Example 1: A sample file. # # a.4j1n b.2j2n90w This file specifies that the a queue, for at jobs, can have up to 4 jobs running simultaneously; those jobs will be run with a nice value of 1. As no nwait value was given, if a job cannot be run because too many other jobs are running cron will wait 60 seconds before trying again to run it. The b queue, for batch(1) jobs, can have up to 2 jobs running simultaneously; those jobs will be run with a nice(1) value of 2. If a job cannot be run because too many other jobs are running, cron(1M) will wait 90 seconds before trying again to run it. All other queues can have up to 100 jobs running simultaneously; they will be run with a nice value of 2, and if a job cannot be run because too many other jobs are running cron will wait 60 seconds before trying again to run it. FILES
/etc/cron.d/queuedefs queue description file for at, batch, and cron. SEE ALSO
at(1), crontab(1), nice(1), cron(1M) SunOS 5.10 1 Mar 1994 queuedefs(4)
All times are GMT -4. The time now is 06:36 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy