- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Query on FIND command -typo
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-29-2011 10:44 PM
тАО05-29-2011 10:44 PM
Query on FIND command -typo
ON a HPUX 11.23 , From an oracle UID a FIND command is executed mistakenly with a typo Error from root (/). I would like to know what the below command would have executed.
$ find . '*.xml' -mtime +2 -exec mv {} /cbrman1/test/audit_fles \;
It said Permission denied for files under /etc/ and still copied some files to /cbrman1/test/audit_fles. But none of the files where MOVED,immedietely we interrupted the command. but it had copied some files from /etc/, /etc/rc.config.d to /cbrman1/xxxxx/xx(without MOVE)
Just need to know what had happened or what impact it would be. Till now, no issues on the server or RAC database. What does this COMMAND represent
- Tags:
- find
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-30-2011 01:18 AM
тАО05-30-2011 01:18 AM
Re: Query on FIND command -typo
$ find . '*.xml' -mtime +2 -exec mv {} /cbrman1/test/audit_fles \;
That command would have gone through all files and sub-directories of the root directory because of "." (i.e. everything) and all files or directories named "*.xml" within the root directory (yes, that's redundant).
It would have recursed into sub-directories without limit, looking for files or directories whose time of last modification was more than 2 full days ago.
It would have attempted to move any files and directories matching the modification time criteria to /cbrman1/test/audit_files, one by one.
I would guess /cbrman1 is a filesystem mount point. A move operation from one filesystem to another is equivalent to making a copy + removing the original.
Of course, the oracle user would have required certain permissions to do so:
- read and access permissions (r-x) to a directory to go through its contents
- permission to read a file (r) to make a duplicate of it to a different filesystem
- full access to any source directory (rwx) to delete any of its contents
- at least write + access permissions to the destination directory to write anything to it (-wx)
Because most of /etc is normally readable and accessible by all users (but not writeable by anyone but root), the mv command could make the copies. But the permissions should have prevented it from deleting the original files. This is probably what caused the majority of the "Permission denied" messages.
Since the older "-exec ... \;" syntax was used, the find command would have created one "mv" command for each file or sub-directory satisfying the modification time condition. This is much less efficient than the newer "-exec ... \+" syntax... which turned out to actually be an advantage in this case.
Besides that the command was run in a wrong directory, I see another possible mistake: instead of
find . '*.xml' ...
the command should most likely have been
find . -name '*.xml' ...
This would have further restricted the command to move only files (or directories) whose name has the '.xml' suffix.
You can see what the command attempted to do by adding "echo" to the -exec command line, like this:
$ find . '*.xml' -mtime +2 -exec echo mv {} /cbrman1/test/audit_fles \;
This will display a long list of "mv
A good safety procedure when constructing "find
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-30-2011 04:58 AM
тАО05-30-2011 04:58 AM
Re: Query on FIND command -typo
You can only use that syntax if that "{}" is at the end. You must write a script that moves the last parm before the first.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-31-2011 10:49 PM
тАО05-31-2011 10:49 PM
Re: Query on FIND command -typo
Regards
Azad
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-01-2011 12:37 AM
тАО06-01-2011 12:37 AM
Re: Query on FIND command -typo
That means all your "permission denied" errors came from the "mv" commands trying to read or delete some file and not having the appropriate permissions.
> So this command will execute even '-name' option is not given. Will it not show syntax error etc..?
No syntax errors, because the command is syntactically valid also without the -name option. Of course, without the option, the meaning is different.
The synopsis of the 'find' command is listed on find(1) man page as:
find [-H|-L] pathname_list [expression]
Let's look at the command, both with and without the '-name' option:
> find . -name '*.xml' ...
Here, the pathname_list part contains only a single element, the current directory. All the rest belongs to the expression part.
> find . '*.xml' -mtime +2 ...
Here, the pathname_list contains multiple elements: the first element is the current directory, and the next is '*.xml'. The find command will process all the pathname_list elements in sequence. It won't stop you if you effectively specify the same thing twice: you might have done it on purpose, after all.
> If it had been executed on root ID-Wouldn't that be a great impact/mess ?
Definitely. Because the command would have moved essential system files and directories like /etc/passwd, it would probably have been impossible to log in. The command might have proceeded to /lib and/or /sbin too: eventually it would have moved /lib/libc.*, after which the regular '/usr/bin/mv' command (and most other commands) would have started to fail.
If the command had processed /sbin before /lib, then /sbin/sh would have been gone and it would not have been possible to reboot the system, even into single user mode. It would have been necessary to boot the system in recovery mode using the installation media to even begin the recovery.
You avoided a system-wide disaster because that command was *not* run as root.
This is exactly why one of the standard recommendations for Unix system administrators is to create separate users for applications (the installation process of Oracle practically forces you to do that) and to grant the appropriate permissions for application files and directories so that the needless use of the root account can be minimized.
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-01-2011 12:39 AM
тАО06-01-2011 12:39 AM
Re: Query on FIND command -typo
I have attached some more outputs on VG for your reference.
YES the VGFLP is presented from EVA SAN 5000 as one LUN.
How would you map device 0x036000, as c3t6d0. Well I couldn't see any type of Harware error or light? How do we check if its gone bad.
I tried using
dd if=/dev/rdsk/c3t6d0 of=dev/null bs=1024. But still its running. One time it came out ,but second time I had a run and still going on. Hope there is no impact on running this. I tend to get more of SCSI errors.
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1539104, sectno: 3078208, offset: 1576042496, bcount: 16384.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 4096,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1539096, sectno: 3078192, offset: 1576034304, bcount: 4096.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 16384,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538828, sectno: 3077656, offset: 1575759872, bcount: 16384.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 4096,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538776, sectno: 3077552, offset: 1575706624, bcount: 4096.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 8192,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538768, sectno: 3077536, offset: 1575698432, bcount: 8192.
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 1538740, sectno: 3077480, offset: 1575669760, bcount: 8192.
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Read error -- dev: b 31 0x036000, errno: 126, resid: 1024,
Jun 1 11:31:50 dopdwdb2 vmunix: SCSI: Write error -- dev: b 31 0x036000, errno: 126, resid: 8192,
Jun 1 11:31:50 dopdwdb2 vmunix: blkno: 8, sectno: 16, offset: 8192, bcount: 1024.
Jun 1 11:31:50 dopdwdb2 vmunix: LVM: VG 64 0x000000: PVLink 31 0x036000 Failed! The PV is not accessible.
Jun 1 11:31:50 dopdwdb2 vmunix:
Jun 1 11:31:56 dopdwdb2 above message repeats 79 times
Jun 1 11:31:55 dopdwdb2 vmunix: LVM: VG 64 0x000000: PVLink 31 0x036000 Recovered.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-01-2011 12:40 AM
тАО06-01-2011 12:40 AM
Re: Query on FIND command -typo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-01-2011 01:59 AM
тАО06-01-2011 01:59 AM