On Linux through the find command rm file deletion tips
- 2020-05-14 05:45:11
- OfStack
We often through find command for batch operation, such as: batch delete old files, batch modification, based on the time of the file statistics, based on the size of the file statistics, etc., among these operations, because rm delete operation can lead to a directory structure change, if you want to by find combining rm operating written script, will encounter a trouble, in this article, through an example to introduce for everybody.
System environment:
SUSE Linux Enterprise Server 11 or
Red Hat Enterprise Linux
Symptoms:
The customer has an automated script on the site with the following find statements that are run daily to delete files or directories that are 7 days old in a directory that is chronologically generating the WAL logs of the PostgreSQL database and its error logs pg_log:
/bin/find /enterprisedb_backup/postgresql/ -mtime +7 -exec /bin/rm -rf '{}' \;
The following errors occur intermittently during operation:
[root@edb ~]# /bin/find /enterprisedb_backup/postgresql/ -mtime +7 -exec /bin/rm -rf {} \;
/bin/find: `/enterprisedb_backup/postgresql/network-scripts': No such file or directory
[root@edb ~]# echo $?
1
Obviously, the above command returned the wrong result, but the customer reported that the data in the directory 7 days ago was deleted after the above script was run.
Problem analysis:
Perform fault recurrence. Run find command separately in another server through simulated data to analyze this problem. The test process is as follows:
1. Simulated data
[root@edbnode1 ~]# date
Wed Jun 18 23:08:18 CST 2014
[root@edbnode1 ~]# cp -rcp /etc/sysconfig/network-scripts/ /enterprisedb_backup/postgresql/
[root@edbnode1 ~]# cp -rcp /etc/init.d/iptables /enterprisedb_backup/postgresql/## Through the above cp -rcp The command holds data copied to the destination directory including: setup time, user root, and so on, to simulate 1 Two old documents and 1 An old directory
[root@edbnode1 ~]# ll /enterprisedb_backup/postgresql/
total 16
-rwxr-xr-x. 1 root root 9409 Oct 31 2012 iptables
drwxr-xr-x. 2 root root 4096 Jun 18 2013 network-scripts## So you can see that iptables The file is 2012 It was established in 1987, network-scripts is 2013 Established in 2001, are far more than 7 day
[root@edbnode1 ~]# ll /enterprisedb_backup/postgresql/*
-rwxr-xr-x. 1 root root 9409 Oct 31 2012 /enterprisedb_backup/postgresql/iptables
/enterprisedb_backup/postgresql/network-scripts:
total 212
-rw-r--r--. 1 root root 159 Jun 18 2013 ifcfg-eth0
-rw-r--r--. 1 root root 203 Jun 18 2013 ifcfg-eth1
-rw-r--r--. 1 root root 203 Jun 18 2013 ifcfg-eth2
-rw-r--r--. 1 root root 254 Jan 9 2013 ifcfg-lo
lrwxrwxrwx. 1 root root 20 Jun 18 2013 ifdown -> ../../../sbin/ifdown
-rwxr-xr-x. 1 root root 627 Jan 9 2013 ifdown-bnep
-rwxr-xr-x. 1 root root 5397 Jan 9 2013 ifdown-eth
-rwxr-xr-x. 1 root root 781 Jan 9 2013 ifdown-ippp
-rwxr-xr-x. 1 root root 4168 Jan 9 2013 ifdown-ipv6
lrwxrwxrwx. 1 root root 11 Jun 18 2013 ifdown-isdn -> ifdown-ippp
-rwxr-xr-x. 1 root root 1481 Jan 9 2013 ifdown-post
-rwxr-xr-x. 1 root root 1064 Jan 9 2013 ifdown-ppp
-rwxr-xr-x. 1 root root 835 Jan 9 2013 ifdown-routes
-rwxr-xr-x. 1 root root 1370 Jan 9 2013 ifdown-sit
-rwxr-xr-x. 1 root root 1434 Jan 9 2013 ifdown-tunnel
lrwxrwxrwx. 1 root root 18 Jun 18 2013 ifup -> ../../../sbin/ifup
-rwxr-xr-x. 1 root root 12365 Jan 9 2013 ifup-aliases
-rwxr-xr-x. 1 root root 859 Jan 9 2013 ifup-bnep
-rwxr-xr-x. 1 root root 10157 Jan 9 2013 ifup-eth
-rwxr-xr-x. 1 root root 11971 Jan 9 2013 ifup-ippp
-rwxr-xr-x. 1 root root 10401 Jan 9 2013 ifup-ipv6
lrwxrwxrwx. 1 root root 9 Jun 18 2013 ifup-isdn -> ifup-ippp
-rwxr-xr-x. 1 root root 727 Jan 9 2013 ifup-plip
-rwxr-xr-x. 1 root root 954 Jan 9 2013 ifup-plusb
-rwxr-xr-x. 1 root root 2364 Jan 9 2013 ifup-post
-rwxr-xr-x. 1 root root 4154 Jan 9 2013 ifup-ppp
-rwxr-xr-x. 1 root root 1925 Jan 9 2013 ifup-routes
-rwxr-xr-x. 1 root root 3499 Jan 9 2013 ifup-sit
-rwxr-xr-x. 1 root root 2488 Jan 9 2013 ifup-tunnel
-rwxr-xr-x. 1 root root 3770 Jan 9 2013 ifup-wireless
-rwxr-xr-x. 1 root root 4623 Jan 9 2013 init.ipv6-global
-rwxr-xr-x. 1 root root 1125 Jan 9 2013 net.hotplug
-rw-r--r--. 1 root root 13079 Jan 9 2013 network-functions
-rw-r--r--. 1 root root 29853 Jan 9 2013 network-functions-ipv6
## So you can see that network-script not 1 Empty directory, there are files, and the files are already 7 It was built days ago 2. Test separately simulated the execution of find + rm instructions in the script
[root@edbnode1 ~]# /bin/find /enterprisedb_backup/postgresql/ -mtime +7 -exec /bin/rm -rf {} \;
/bin/find: `/enterprisedb_backup/postgresql/network-scripts': No such file or directory
[root@edbnode1 ~]# echo $?
1
[root@edbnode1 ~]# ls /enterprisedb_backup/postgresql/
[root@edbnode1 ~]#
You can see that the find operation did return incorrect results, but a look at the data backup directory shows that the iptables files and the network-scripts directory have been deleted correctly
3. Since the data that has been deleted right, so we started to doubt by network - scripts directory delete after find continue to try to delete the directory other files, lead to not "No such file or directory" mistakes, so you need't step 1 to confirm this conjecture, to implement the above data in "step 1" environmental simulation, and perform the following operations, mainly converting rm ls to show the whole operation process:
[root@edbnode1 ~]# cp -rcp /etc/sysconfig/network-scripts/ /enterprisedb_backup/postgresql/
[root@edbnode1 ~]# cp -rcp /etc/init.d/iptables /enterprisedb_backup/postgresql/
[root@edbnode1 ~]# /bin/find /enterprisedb_backup/postgresql/ -mtime +7 -exec /bin/ls {} \;
ifcfg-eth0 ifcfg-lo ifdown-eth ifdown-isdn ifdown-routes ifup ifup-eth ifup-isdn ifup-post ifup-sit init.ipv6-global network-functions-ipv6
ifcfg-eth1 ifdown ifdown-ippp ifdown-post ifdown-sit ifup-aliases ifup-ippp ifup-plip ifup-ppp ifup-tunnel net.hotplug
ifcfg-eth2 ifdown-bnep ifdown-ipv6 ifdown-ppp ifdown-tunnel ifup-bnep ifup-ipv6 ifup-plusb ifup-routes ifup-wireless network-functions
/enterprisedb_backup/postgresql/network-scripts/ifup-plusb
/enterprisedb_backup/postgresql/network-scripts/ifup-sit
/enterprisedb_backup/postgresql/network-scripts/ifdown-post
/enterprisedb_backup/postgresql/network-scripts/ifcfg-lo
/enterprisedb_backup/postgresql/network-scripts/network-functions
/enterprisedb_backup/postgresql/network-scripts/ifup-bnep
/enterprisedb_backup/postgresql/network-scripts/ifup-ippp
/enterprisedb_backup/postgresql/network-scripts/ifdown-sit
/enterprisedb_backup/postgresql/network-scripts/ifdown-tunnel
/enterprisedb_backup/postgresql/network-scripts/ifup-plip
/enterprisedb_backup/postgresql/network-scripts/ifup-eth
/enterprisedb_backup/postgresql/network-scripts/ifdown-ipv6
/enterprisedb_backup/postgresql/network-scripts/ifdown-ippp
/enterprisedb_backup/postgresql/network-scripts/ifup-aliases
/enterprisedb_backup/postgresql/network-scripts/network-functions-ipv6
/enterprisedb_backup/postgresql/network-scripts/ifup-ipv6
/enterprisedb_backup/postgresql/network-scripts/ifup-post
/enterprisedb_backup/postgresql/network-scripts/ifcfg-eth2
/enterprisedb_backup/postgresql/network-scripts/ifcfg-eth1
/enterprisedb_backup/postgresql/network-scripts/ifdown-ppp
/enterprisedb_backup/postgresql/network-scripts/ifup-isdn
/enterprisedb_backup/postgresql/network-scripts/ifcfg-eth0
/enterprisedb_backup/postgresql/network-scripts/ifdown
/enterprisedb_backup/postgresql/network-scripts/ifup-wireless
/enterprisedb_backup/postgresql/network-scripts/ifup-ppp
/enterprisedb_backup/postgresql/network-scripts/ifdown-eth
/enterprisedb_backup/postgresql/network-scripts/init.ipv6-global
/enterprisedb_backup/postgresql/network-scripts/ifdown-isdn
/enterprisedb_backup/postgresql/network-scripts/ifup-tunnel
/enterprisedb_backup/postgresql/network-scripts/ifdown-routes
/enterprisedb_backup/postgresql/network-scripts/ifdown-bnep
/enterprisedb_backup/postgresql/network-scripts/net.hotplug
/enterprisedb_backup/postgresql/network-scripts/ifup
/enterprisedb_backup/postgresql/network-scripts/ifup-routes
/enterprisedb_backup/postgresql/iptablesFrom the above we can see that the find command not only queried the /enterprisedb_backup/postgresql/ directory, but also traversed all subdirectories, thus supporting our inference
4. To sum up, the basic positioning problem mentioned above
Solutions:
1. After sorting out the ideas, it can be confirmed that if find only finds the layer 1 files and directories of the required operation directory, this problem can be solved
2. Through the great man command we get the following information
-maxdepth levels
Descend at most levels (a non-negative integer) levels of directories below the command line arguments. -maxdepth 0 means only apply the tests and actions to the command line arguments.
3. Confirm and modify the test operation as follows:
[root@edbnode1 ~]# /bin/find /enterprisedb_backup/postgresql/ -mtime +7 -maxdepth 1 -exec /bin/rm -rf {} \;
/bin/find: warning: you have specified the -maxdepth option after a non-option argument -mtime, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments.
This means: -mtime may find information that crosses the range of -maxdepth, and it is recommended in the find operation that -maxdepth precede all other parameters
Solution result [completed]