Tips for RM file deletion with the Find command under Linux

We often use the Find command to bulk operations, such as: bulk delete old files, batch modification, time-based file statistics, file size based file statistics, etc., in these operations, because the RM delete operation will cause the directory structure changes, if you want to use the operation of the find combined with RM script, Will encounter some trouble, this article through an example for everyone to introduce.

System environment:

SUSE Linux Enterprise Server 11 or

Red Hat Enterprise Linux

Symptoms of the problem:

The customer site has an automated script with the following find statement, which runs daily to delete files or directories that were 7 days old in a directory that were generated in chronological order with the Wal log of the PostgreSQL database and its error log pg_log:

/bin/find/enterprisedb_backup/postgresql/-mtime +7-exec/bin/rm-rf ' {} ';

During the run, the following error occurs intermittently:

[Email protected] ~]#/bin/find/enterprisedb_backup/postgresql/-mtime +7-exec/bin/rm-rf {} \;/bin/find: '/enterprise Db_backup/postgresql/network-scripts ': No such file or Directory[[email protected] ~]# echo $?1

Obviously, the above command returned the wrong result, but the customer said that the data was deleted 7 days before the script was run.

Problem Analysis:

Perform a failure replay, run the Find command separately from the simulation data on another server to analyze the problem, and the test process is as follows:

1. Analog data
   

   [Email protected] ~]# datewed June 23:08:18 CST 2014[[email protected] ~]# cp-rcp/etc/sysconfig/network-scripts//ent Erprisedb_backup/postgresql/[[email protected] ~]# cp-rcp/etc/init.d/iptables/enterprisedb_backup/postgresql/

   # # above the data that is copied to the target directory by the CP-RCP command includes information such as build time, user rights root, to simulate an old file and an old directory

   [Email protected] ~]# ll/enterprisedb_backup/postgresql/total 16-rwxr-xr-x. 1 root root 9409 Oct  iptablesdrwxr-xr-x. 2 root root 4096 June  network-scripts

   # # above can see the Iptables file was established in 2012, Network-scripts was established in 2013, are far more than 7 days

   [[email protected] ~]# ll/enterprisedb_backup/postgresql/*-rwxr-xr-x. 1 root root 9409 Oct to 2012/enterprisedb_backup/postgresql/iptables/enterprisedb_backup/postgresql/network-scripts: Total 212-rw-r--r--. 1 root root 159 June Ifcfg-eth0-rw-r--r--. 1 root root 203 June Ifcfg-eth1-rw-r--r--. 1 root root 203 June Ifcfg-eth2-rw-r--r--. 1 root root 254 Jan 9 ifcfg-lolrwxrwxrwx. 1 root root June ifdown. /.. /.. /sbin/ifdown-rwxr-xr-x. 1 root root 627 Jan 9 ifdown-bnep-rwxr-xr-x. 1 root root 5397 Jan 9 ifdown-eth-rwxr-xr-x. 1 root root 781 Jan 9 ifdown-ippp-rwxr-xr-x. 1 root root 4168 Jan 9 ifdown-ipv6lrwxrwxrwx. 1 root root One June ifdown-isdn, Ifdown-ippp-rwxr-xr-x. 1 root root 1481 Jan 9 ifdown-post-rwxr-xr-x. 1 root root 1064 Jan 9 ifdown-ppp-rwxr-xr-x. 1 root root 835 Jan 9 ifdown-routes-rwxr-xr-x. 1 root root 1370 Jan 9 IFDOWN-SIT-RWXR-XR-X. 1 root root 1434 Jan 9 ifdown-tunnellrwxrwxrwx. 1 root root: ifup. /.. /.. /sbin/ifup-rwxr-xr-x. 1 root root 12365 Jan 9 ifup-aliases-rwxr-xr-x. 1 root root 859 Jan 9 ifup-bnep-rwxr-xr-x. 1 root root 10157 Jan 9 ifup-eth-rwxr-xr-x. 1 root root 11971 Jan 9 ifup-ippp-rwxr-xr-x. 1 root root 10401 Jan 9 ifup-ipv6lrwxrwxrwx. 1 root root 9 June ifup-isdn-Ifup-ippp-rwxr-xr-x. 1 root root 727 Jan 9 ifup-plip-rwxr-xr-x. 1 root root 954 Jan 9 ifup-plusb-rwxr-xr-x. 1 root root 2364 Jan 9 ifup-post-rwxr-xr-x. 1 root root 4154 Jan 9 ifup-ppp-rwxr-xr-x. 1 root root 1925 Jan 9 ifup-routes-rwxr-xr-x. 1 root root 3499 Jan 9 ifup-sit-rwxr-xr-x. 1 root root 2488 Jan 9 ifup-tunnel-rwxr-xr-x. 1 root root 3770 Jan 9 ifup-wireless-rwxr-xr-x. 1 root root 4623 Jan 9 init.ipv6-global-rwxr-xr-x. 1 root root 1125 Jan 9 net.hotplug-rw-r--r--. 1Root root 13079 Jan 9 network-functions-rw-r--r--. 1 root root 29853 Jan 9 Network-functions-ipv6

   # # above you can see that network-script is not an empty directory, there are files, and the files have been established 7 days ago
   
   

3. Test the Find + RM directive in a separate simulation execution script
   

   [Email protected] ~]#/bin/find/enterprisedb_backup/postgresql/-mtime +7-exec/bin/rm-rf {} \;/bin/find: '/enterprise Db_backup/postgresql/network-scripts ': No such file or Directory[[email protected] ~]# echo $?1[[email protected] ~]# ls/ Enterprisedb_backup/postgresql/[[email protected] ~]#

   You can see that the find operation did return the wrong result, but view the data backup directory discovery, the Iptables file and the Network-scripts directory have been correctly deleted
   
   
4. Since the data was deleted correctly, so we started to suspect that after the network-scripts directory was deleted, find continues to try to delete the other files in this directory, resulting in no "No such file or directory" errors, and therefore need to further confirm this conjecture, Re-perform the Data Environment simulation in step 1th above, and perform the following operations, mainly converting RM to LS to demonstrate the overall operation process:
   

   [[email protected] ~]# cp-rcp/etc/sysconfig/network-scripts//enterprisedb_backup/postgresql/[[email  Protected] ~]# cp-rcp/etc/init.d/iptables/enterprisedb_backup/postgresql/[[email protected] ~]#/bin/find/  enterprisedb_backup/postgresql/-mtime +7-exec/bin/ls {} \;ifcfg-eth0 ifcfg-lo ifdown-eth ifdown-isdn ifdown-routes Ifupifup-eth ifup-isdn ifup-post ifup-sit init.ipv6-global network-functions-ipv6ifcfg-eth1 ifdown Ifdown-ipp P ifdown-post ifdown-sit ifup-aliasesifup-ippp ifup-plip ifup-ppp ifup-tunnel net.hotplugifcfg-eth2 ifdown-b NEP Ifdown-ipv6 ifdown-ppp ifdown-tunnel ifup-bnepifup-ipv6 ifup-plusb ifup-routes ifup-wireless network-function s/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 /iptables

   From the above we can see that the find command not only queries the/enterprisedb_backup/postgresql/directory, but also iterates through all subdirectories, thus supporting our inference
   
   
6. In summary, the basic positioning problem lies
   

Analysis Diagram:

I don't know how to draw this picture.

Solution:

2. After sorting out your ideas, you can confirm that if find only finds the 1th level of files and directories in the directory you want to work with, this problem will be resolved
4. Through the great man command we get the following information
   

   -maxdepth levels    

   
   
6. The test action confirmation is modified to:
   

   [Email protected] ~]#/bin/find/enterprisedb_backup/postgresql/-mtime +7-maxdepth 1-exec/bin/rm-rf {} \;/bin/find: Warning:you has specified the-maxdepth option after a non-option argument-mtime, but options is not positional (-maxd Epth affects tests specified before it as well as those specified after it).  Specify options before other arguments.

   This means that the information found by-mtime may have been over the-maxdepth range, and it is recommended that-maxdepth be placed in front of all other parameters in the find operation
   
   
8. Use Jndi or other public methods to connect in the JBoss framework, and avoid database connection by calling Getconnection directly in Java program;
   

   [Email protected] ~]#/bin/find/enterprisedb_backup/postgresql/-maxdepth 1-mtime +7-exec/bin/rm-rf {} \;

   
   

Resolve result "Done"