Modified Date

kernelzack · 07-03-2009, 04:52 PM

GET IT THROUGH YOUR HEAD, NO UPDATES NO COPYING FILES FROM ONE SERVER TO ANOTHER. You are completely incorrect and you misunderstood my question, I have a back end server that "CREATES" files based on other conditions, not updates or transfers, YOU QUOTED ME AS SAYING SUCH SO I'M NOT SURE WHAT YOUR ARE TALKING ABOUT. You are wrong you read it wrong and you told me that I was a little kid playing around and you are the one who is now trying to save face.

"Please dont go through the definitions only use your mind and think
logically. Thats really work.Always try to relate the concepts an this really help you"

I tried but i really don't think you believe so sometimes it helps little kids to see information from other sources. I truly believe as you quoted me as saying "backend servers" and then stated that I wrote something about backup servers, that you did not know the difference, so instead of you arguing w/ me that i was wrong, I showed you cold proof. I am glad to hear you learned something today you should really take some of your own advice.

kernelzack · 07-03-2009, 04:55 PM

Quote:

Originally Posted by unSpawn

Could you both please stop the bickering and just focus on solving the problem?

Sorry, this is getting out of hand I agree.

osor · 07-03-2009, 06:05 PM

Quote:

Originally Posted by kernelzack

i'm not sure as to how a file date can go back in time without a user running touch on it.

Well, touch itself is a program, and any program can be written with its functionality. Basically, any POSIX/XSI program can use the function utimes(), futimens(), or utimensat() to change modification dates for files. There are probably also system-specific methods to do this. So you have infinitely-many possible reasons this could be happening. Many programs known to do this (e.g., rsync, tar, etc.) are often used in a backup context, so this is probably why backup was assumed. On the other hand, you have been sparse on actual details, so there is nothing more specific to be said.

osor · 07-03-2009, 06:33 PM

Btw, you might try a kernel-level file monitor and logger such as tripwire to see what process makes those system calls.

kernelzack · 07-03-2009, 06:52 PM

Quote:

Originally Posted by osor

Btw, you might try a kernel-level file monitor and logger such as tripwire to see what process makes those system calls.

Awesome thanks alot, that is the route I will take. What more would you like me to provide?

unSpawn · 07-03-2009, 08:38 PM

Quote:

Originally Posted by osor

Btw, you might try a kernel-level file monitor and logger such as tripwire to see what process makes those system calls.

tripwire doesn't log syscalls AFAIK but Samhain could via the "LogCalls" option. Elif the OP is running a 2.6 kernel RHEL or EL-like derivative chances are Auditd is already installed. Using 'auditctl' it is possible to add rules to log all syscalls (Samhain only logs a limited set) by say setting a watch on a directory. However this will not provide as much information as stracing the app may.

osor · 07-03-2009, 10:10 PM

Quote:

Originally Posted by kernelzack

What more would you like me to provide?

What I meant was that it is not clear from your posts if this is a recurring problem or if there are any patterns associated with it (e.g., Is it always that single file in the directory? When does this happen in relation to running your server process? How often does it happen? Is it always set to the same date? Etc.). So far, you have elaborated a single incident/anecdote and tried lsof, yet a file need not be “open” prior to modifying its date. You have previously stated that the particular server setup would take awhile to explain, yet it seems that that some details are needed to look for perhaps common pathways (e.g., if it an open-source program, you can simply grep its sourcecode for for starters).

Quote:

Originally Posted by unSpawn

tripwire doesn't log syscalls AFAIK but Samhain could via the "LogCalls" option. Elif the OP is running a 2.6 kernel RHEL or EL-like derivative chances are Auditd is already installed. Using 'auditctl' it is possible to add rules to log all syscalls (Samhain only logs a limited set) by say setting a watch on a directory.

Thank’s for pointing that out. Tripwire was the first thing that came to mind, but I assumed it created its own struct file_operations or struct security_operations in a kernel module (so instead of logging system calls, it would log file operations). There is at least one other that provides this sort of linux module, though I can’t presently recall the name (perhaps it was a fuse filesystem).

Quote:

Originally Posted by unSpawn

However this will not provide as much information as stracing the app may.

Yes, but it is not clear what the app is. Although the “server” in this case is supposed to do some stuff with the file, it is not clear if something unrelated (and/or perhaps nefarious) is doing the time changing.

wje_lq · 07-03-2009, 10:32 PM

Quote:

Originally Posted by unSpawn

tripwire doesn't log syscalls AFAIK but Samhain could via the "LogCalls" option. Elif the OP is running a 2.6 kernel RHEL or EL-like derivative chances are Auditd is already installed.

On a completely irrelevant note (which I hope doesn't hijack the thread), this is the first time I have ever seen the word "elif" used in an English sentence (as opposed to a shell script). It was used perfectly correctly, too. My hat's off to you, unSpawn.

kernelzack · 07-04-2009, 10:24 AM

Quote:

Originally Posted by osor

What I meant was that it is not clear from your posts if this is a recurring problem or if there are any patterns associated with it (e.g., Is it always that single file in the directory? When does this happen in relation to running your server process? How often does it happen? Is it always set to the same date? Etc.). So far, you have elaborated a single incident/anecdote and tried lsof, yet a file need not be “open” prior to modifying its date. You have previously stated that the particular server setup would take awhile to explain, yet it seems that that some details are needed to look for perhaps common pathways (e.g., if it an open-source program, you can simply grep its sourcecode for for starters).

Thank’s for pointing that out. Tripwire was the first thing that came to mind, but I assumed it created its own struct file_operations or struct security_operations in a kernel module (so instead of logging system calls, it would log file operations). There is at least one other that provides this sort of linux module, though I can’t presently recall the name (perhaps it was a fuse filesystem).
Yes, but it is not clear what the app is. Although the “server” in this case is supposed to do some stuff with the file, it is not clear if something unrelated (and/or perhaps nefarious) is doing the time changing.

This problem has only happened once to only one file. The process does run nightly and depending on how many input files are there and it is set to a single date.There are multiple files in the directory, It is closed source unfortunately, the server is basically fed input files and judging by the content it will create a new file. While creating the file it pulls the data from the input file and puts it into the appropriate location on the data server, once complete it creates the file in question. Which I have seen it do plenty of times, I have just never seen the file date revert back. Thanks! for the advice osor and unspawn, I will try that out and let you know how it goes. Thanks for bearing with me I know this sounds very unlikely!

kike_coello · 07-04-2009, 11:32 AM

i know right?

osor · 07-05-2009, 02:10 PM

Quote:

Originally Posted by kernelzack

This problem has only happened once to only one file.

Well, the methods shown above will only “catch it in the act” (they obviously cannot find what happened to the old file).

Quote:

Originally Posted by kernelzack

I have just never seen the file date revert back.

Well, it is a rare thing to see, and even if it is happening in 1 in 1000 files, it is a rare thing to notice. So if this is symptomatic of a large problem or functionality, then you might find it. There is, however, always a chance that the first one was just a fluke.