Monitor changes to a file

Mike Ballon mike.ballon at gmail.com
Wed Mar 2 06:12:30 MST 2011


You could also try using strace as well, although maybe I just don't
understand exactly what you need. Note; if the script doesn't run long
enough it's hard to catch the data. For example when I ran dd below with a
count of 1000 both text files were empty. I ran this as myself and root, the
results were as expected.

#crontab.txt
* * * * * dd if=/dev/zero of=openfile bs=8k count=10000
* * * * * fuser openfile > fuser.txt
* * * * * lsof | grep openfile > lsof.txt

cat fuser.txt
2659
cat lsof.txt
dd        2659    $USER    1w      REG        8,2 59416576    1060541
/home/$USER/openfile



On Tue, Mar 1, 2011 at 6:43 PM, Kurt Granroth <
kurt+plug-discuss at granroth.com> wrote:

> I tried a script using incron last night and it implied that it was
> happening exactly when SpiderOak was starting up.  I say "implied" because
> it effectively fork-bombed me (lesson learned: don't use IN_ALL_EVENTS) and
> my log file was all corrupted when I had to reboot.
>
> On 3/1/11 9:19 AM, Dazed_75 wrote:
>
>> Given that you said "... corrupting or rewriting a critical file _just
>> before_ it runs", would it be worth renaming, removing or changing
>> permissions on the file just before that to see what fails or logs an
>> error?
>>
>> Larry
>>
>> On Tue, Mar 1, 2011 at 8:14 AM, Alex Dean <alex at crackpot.org
>> <mailto:alex at crackpot.org>> wrote:
>>
>>
>>    On Feb 28, 2011, at 5:33 PM, Kurt Granroth wrote:
>>
>>     > Maybe incron (cron version of inotify) could trigger a script
>>    that runs 'stat' on the file.  Still wouldn't give me the "who",
>> though.
>>
>>    At first glance, I thought inotify would be perfect for this.  But
>>    (as you say) it doesn't appear that inotify events contain any
>>    information about which process performed the change which trigged
>>    the event.
>>
>>    struct inotify_event {
>>            __s32 wd;             /* watch descriptor */
>>            __u32 mask;           /* watch mask */
>>            __u32 cookie;         /* cookie to synchronize two events */
>>            __u32 len;            /* length (including nulls) of name */
>>            char name[0];        /* stub for possible name */
>>    };
>>    http://www.linuxjournal.com/article/8478?page=0,1
>>
>>    There are some handy-looking tools in
>>    https://github.com/rvoicilas/inotify-tools/wiki/.  Seems like you
>>    should be able to write a shell script to wait for a modification
>>    event on your file, and run stat or lsof when the file is changed.
>>      That's not perfect, since the modifying process might be done by
>>    the time lsof actually runs, but it seems like it's worth a try.
>>
>>    alex
>>    ---------------------------------------------------
>>    PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>>    <mailto:PLUG-discuss at lists.plug.phoenix.az.us>
>>    To subscribe, unsubscribe, or to change your mail settings:
>>    http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>>
>>
>>
>> --
>> Dazed_75 a.k.a. Larry
>>
>> The spirit of resistance to government is so valuable on certain
>> occasions, that I wish it always to be kept alive.
>>   - Thomas Jefferson
>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110302/4b8ae5b8/attachment.html>


More information about the PLUG-discuss mailing list