LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices


Reply
  Search this Thread
Old 01-25-2017, 07:55 AM   #16
TenTenths
Senior Member
 
Registered: Aug 2011
Location: Dublin
Distribution: Centos 5 / 6 / 7
Posts: 3,088

Rep: Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303Reputation: 1303

Very baffling, I'm wondering if somewhere along the line the cron job is having issues around attribute caching:

Quote:
http://docstore.mik.ua/orelly/networ...fs/ch18_06.htm

"NFS clients cache file attributes such as the modification time and owner to avoid having to go to the NFS server for information that does not change frequently."
 
1 members found this post helpful.
Old 01-25-2017, 07:56 AM   #17
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 15,164

Rep: Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984
actually the environment of cron is very limited. Try to execute env from your shell and from your crontab, probably you will see some difference (for example locale related)
How are those drives are shared/mounted?
 
1 members found this post helpful.
Old 01-25-2017, 08:39 AM   #18
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,449

Rep: Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037
Quote:
Originally Posted by pan64 View Post
You cannot use: find <file>
Yes, you absolutely can do that. There will obviously be no recursion if the name is not a directory.
Code:
[rkn] ~ $ find /etc/profile
/etc/profile
[rkn] ~ $ find /etc/profile -ls
    48    4 -rw-r--r--   1 root     root         1796 Oct  2  2013 /etc/profile
[rkn] ~ $ find /etc/pro*
/etc/profile
/etc/profile.d
/etc/profile.d/udisks-bash-completion.sh
/etc/profile.d/lang.sh
/etc/profile.d/qt.sh
/etc/profile.d/cvs.sh
/etc/profile.d/cvs.csh
/etc/profile.d/gnome-ssh-askpass.csh
/etc/profile.d/lang.csh
/etc/profile.d/vim.sh
/etc/profile.d/colorls.csh
/etc/profile.d/less.sh
/etc/profile.d/glib2.sh
/etc/profile.d/less.csh
/etc/profile.d/vim.csh
/etc/profile.d/colorls.sh
/etc/profile.d/gnome-ssh-askpass.sh
/etc/profile.d/which2.sh
/etc/profile.d/glib2.csh
/etc/profile.d/qt.csh
/etc/protocols
In that third example, is the shell, not find, that is expanding the wildcard. The command that is actually executed is "find /etc/profile /etc/profile.d /etc/protocols".

Last edited by rknichols; 01-25-2017 at 08:44 AM.
 
Old 01-25-2017, 08:47 AM   #19
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 15,164

Rep: Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984
Quote:
Originally Posted by rknichols View Post
Yes, you absolutely can do that. There will obviously be no recursion if the name is not a directory.
Code:
[rkn] ~ $ find /etc/profile
/etc/profile
[rkn] ~ $ find /etc/profile -ls
    48    4 -rw-r--r--   1 root     root         1796 Oct  2  2013 /etc/profile
[rkn] ~ $ find /etc/pro*
/etc/profile
/etc/profile.d
/etc/profile.d/udisks-bash-completion.sh
/etc/profile.d/lang.sh
/etc/profile.d/qt.sh
/etc/profile.d/cvs.sh
/etc/profile.d/cvs.csh
/etc/profile.d/gnome-ssh-askpass.csh
/etc/profile.d/lang.csh
/etc/profile.d/vim.sh
/etc/profile.d/colorls.csh
/etc/profile.d/less.sh
/etc/profile.d/glib2.sh
/etc/profile.d/less.csh
/etc/profile.d/vim.csh
/etc/profile.d/colorls.sh
/etc/profile.d/gnome-ssh-askpass.sh
/etc/profile.d/which2.sh
/etc/profile.d/glib2.csh
/etc/profile.d/qt.csh
/etc/protocols
Oh yes, almost. Your second example is a bit strange, because /etc/pro* is expanded by the shell and the result is passed to find. find '/etc/pro*' does not find anything. Obviously you can try to find files that way, but that is not efficient and in general using find that way is a bit pointless, but possible.
 
Old 01-25-2017, 08:54 AM   #20
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,449

Rep: Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037Reputation: 2037
Quote:
Originally Posted by pan64 View Post
Oh yes, almost. Your second example is a bit strange, because /etc/pro* is expanded by the shell and the result is passed to find.
Yes, while you were writing your reply I added some text explaining that.
 
Old 01-26-2017, 12:18 AM   #21
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,540

Original Poster
Rep: Reputation: 101Reputation: 101
Quote:
Originally Posted by TenTenths View Post
Very baffling, I'm wondering if somewhere along the line the cron job is having issues around attribute caching:
Interesting, that might explain exactly the behaviour I'm seeing...!
 
Old 01-26-2017, 12:26 AM   #22
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,540

Original Poster
Rep: Reputation: 101Reputation: 101
Quote:
Originally Posted by pan64 View Post
actually the environment of cron is very limited. Try to execute env from your shell and from your crontab, probably you will see some difference (for example locale related)
How are those drives are shared/mounted?
That's the whole thing, a world of difference when running find from the shell / a terminal session and running it from cron - behaviour as regards NFS shares varies drastically, from working in shell to not working at all when called from cron on an absolute NFS shared path.

The actual physical drive is mounted on my "System B" using:

Code:
mount /dev/sdc1 /mnt/Development
The "voiceArchive" folder is a sub-folder of the ext4-formatted sdc1 SATA HDD mounted to /mnt/Development, plugged into the PSU and motherboard of "System B".

"System B" then shares this drive over NFS to "System A" (where find malfunctions as regards mtime if asked to do so on the NFS share) via this /etc/exports line on "System B":

Code:
#cat /etc/exports | grep 192.168.10.2
/mnt/Development/VoiceRecording         192.168.10.2(rw,sync,no_root_squash)
#
As another guru mentioned, if the NFS client code on System A caches attributes including mtime (?), maybe I can add a parameter to the exports line to make mtime over NFS work?

I'll dig into some man pages on that.

Thanks for the assistance!

Stefan
 
Old 01-26-2017, 01:15 AM   #23
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 15,164

Rep: Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984Reputation: 4984
see man mount and man nfs about options can be used when you mount an nfs drive. Probably you will find some of them usable for you (for example noac)
 
1 members found this post helpful.
Old 01-31-2017, 02:17 AM   #24
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,540

Original Poster
Rep: Reputation: 101Reputation: 101
Hi all

Thanks for the replies to the thread.

I think this is now working.

I did not touch the NFS mount point options or change the script from the BASH code listed above.

I left the server alone for a few days, and lo and behold it is now trimming the tail-end files by date as it was supposed to do.

Not sure why it started working, most likely I had some kind of date or time issue on the server causing find to not detect the older files as intended, and therefore not deleting them.

I noticed if I do

Code:
ls -l
the dates on the files vary widely from if I do

Code:
ls --full-time -l
By the times listed in ls --full-time, my file dates were too recent to be deleted.

By the times listed in ls -l, my file dates were old enough to be supposed to be deleted.

So the files had two sets of dates, and it seems that the find command as listed above in my backup script was evaluating the --full-time results - once they had drifted far enough into the past (as the clock time advanced on the server) they got deleted - but the ls -l times were always already quite far in the past, so that is why I thought something was wrong.

It is working now... the net effect is just that visual dates via ls -l are often now more than a week in the past, before the file is deleted by --full-time time which always is much more recent than the ls -l time on the same file.

The "find" GNU binutil is apparently evaluating by "ls --full-time" time, NOT "ls -l" time, when deciding if a file is old enough seen against the -mtime parameter, to have a command (delete, ls, whatever) executed on it.

Strange...

But the LOGIC of the find mtime command IS working on my NFS share, it is only operating on a time that is not the time shown by ls -l for files on that NFS share.

Thx again for everybody's time and assistance.

Regards

Stefan

Last edited by rylan76; 02-01-2017 at 07:57 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] yum-cron is not working on CentOS 5.10 kkpal Linux - Server 4 05-26-2014 11:15 PM
[SOLVED] Not sure why this command isn't working under bash and cron cheddarcheese Linux - Newbie 4 05-12-2013 10:04 AM
cron not working in CentOS 6 sabeel_ansari Red Hat 6 08-16-2012 11:29 AM
Cron Not Working on CentOS carlosinfl Linux - Server 7 01-04-2012 12:48 PM
same find command not working in bash script, quotes? QuakerOatz Linux - Software 1 07-14-2003 12:04 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 04:01 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration