On Thursday 27 November 2008 12:00:11 Vladimir Dronnikov wrote:
> > According to http://www.linuxjournal.com/article/8478 - close() will do
> > all the required cleanup job.
>
> It was you, Piotr, who requested for ...to have inotify_rm_watch() for each
> inotify_add_watch() call... :)
> I, persona
>
> In my code if I open I close; the same with the add - remove pair.
>
close()ing files and free()ing memory are likely to have sence when
iteratively working with unlimited or potentially large number of these
resources. At least, it is common practice in BB. Just let us trust the
system.
Best
Vladimir,
1. When I was discovering that the inotify existed you were already an expert.
2. In my code if I open I close; the same with the add - remove pair.
3. Now I know that inotify can remove some watches internally and the close()
was implemented to do all the required cleanup. So I would j
>
> According to http://www.linuxjournal.com/article/8478 - close() will do
> all the required cleanup job.
>
It was you, Piotr, who requested for ...to have inotify_rm_watch() for each
inotify_add_watch() call... :)
I, personally, turn FEATURE_CLEAN_UP off and rely upon the system
housekeeping.
According to http://www.linuxjournal.com/article/8478 - close() will do all the
required cleanup job.
"To destroy any existing watches, pending events and the inotify instance
itself, invoke the close() system call on the inotify instance's file
descriptor."
Best Regards,
Piotr
I would g
>
> I would gladly review a patch ;)
Well, take a look at http://drvv.ru/busybox/inotifyd.patch .
If it fits, please apply.
--
Vladimir
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
An old habit. I trust nobody; always prefer cleanup after myself.
Piotr
> Hi Piotr,
>
> Your Date: seems to be off: 2008-09-25??
>
> On Thursday 25 September 2008 18:24, Piotr Grudzinski wrote:
>> Would it be too much of a trouble to have inotify_rm_watch()
>> for each inotify_add_watch()
>
>
On Tuesday 25 November 2008 19:13, Vladimir Dronnikov wrote:
> > Would it be too much of a trouble to have inotify_rm_watch() for each
> > inotify_add_watch() call and a close() matching inotify_init()?
> >
>
> Not at all. But the final close() is performed by the system at exit(), I
> believe. N
Hi Piotr,
Your Date: seems to be off: 2008-09-25??
On Thursday 25 September 2008 18:24, Piotr Grudzinski wrote:
> Would it be too much of a trouble to have inotify_rm_watch()
> for each inotify_add_watch()
Why?
> call and a close() matching inotify_init()?
Why^2?
--
vda
___
> Would it be too much of a trouble to have inotify_rm_watch() for each
> inotify_add_watch() call and a close() matching inotify_init()?
>
Not at all. But the final close() is performed by the system at exit(), I
believe. Nevertheless, we can wrap these calls with ENABLE_CLEANUP.
Denys, what do
Would it be too much of a trouble to have inotify_rm_watch() for each
inotify_add_watch() call and a close() matching inotify_init()?
Piotr___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
> inotifyd agent file
> differs from
> inotifyd agent file1 file2
> This is easy to fix.
Elegantly solved!
Also I noticed bugs:
- unsigned mask = IN_ALL_EVENTS done just once,
> must be done before each file
In fact it was intended. Specified mask was meant to propagate through
subsequen
On Tuesday 18 November 2008 18:33, Vladimir Dronnikov wrote:
> >
> > So we should implicitly add IN_IGNORED to the watching mask regardless the
> > user specified it on not. Then, after we have wait()ed for the agent, we
> > should check whether IN_IGNORED is in received event mask, and exit if it
So I applied patches to inotifyd.c from SVN and can see the same problem. If
the only event is IN_IGNORED
the 'goto done' will never be executed.
I tried it with BB 1.12.1.
Always apply patches against current SVN unless the precise version is
specified, Piotr. I should have told that, s
>
> I tried it with BB 1.12.1.
>
Always apply patches against current SVN unless the precise version is
specified, Piotr. I should have told that, sorry.
1.12.1 has no knowledge of IN_IGNORED.
Please, try again current SVN?
--
Vladimir
___
busybox mail
I tried it with BB 1.12.1. If the only event is IN_IGNORED (0x8000) the if(m)
is false and 'goto done' is never executed.
On my system the agent program is always called with one event at a time.
Piotr
So we should implicitly add IN_IGNORED to the watching mask regardless the
user specifie
>
> So we should implicitly add IN_IGNORED to the watching mask regardless the
> user specified it on not. Then, after we have wait()ed for the agent, we
> should check whether IN_IGNORED is in received event mask, and exit if it
> is. Right?
>
Denys, please, take a look. May be so: http://drvv.ru
>
> it's a better way to catch all other weird ways inode can disappear by
> watching specifically
> for IN_IGNORED
>
> Since watching after IN_IGNORED is pointless, exiting after this
> might be useful for largish group of users.
So we should implicitly add IN_IGNORED to the watching mask regard
On Monday 17 November 2008 18:18, Piotr Grudzinski wrote:
> Will try it later.
> But, with this solution, it seems that my handler is left waiting for events
> after it was told not to expect any anymore.
You can specify file:MD in order to catch "Delete" event.
I just checked: if I do "mv other_f
I have tried it with BB 1.12.1. Seems to be OK.
Thanks,
Piotr
When the watched file becomes invalid, the agent program has to be informed
about it and inotifyd should terminate.
I think it is purely agent's headache. Your scenario is one special case,
Piotr -- how many another ones you
>
> When the watched file becomes invalid, the agent program has to be informed
> about it and inotifyd should terminate.
>
I think it is purely agent's headache. Your scenario is one special case,
Piotr -- how many another ones you think should we hardcode into inotifyd?
Let's keep inotifyd dumb
When the watched file becomes invalid, the agent program has to be informed
about it and inotifyd should terminate.
Piotr
inotify listens to changes to inode, not file name. mv f1 f2 effectively
_deletes_ target file if the latter exists. Thus, the watch becomes invalid.
This behaviour is i
inotify listens to changes to inode, not file name. mv f1 f2 effectively
_deletes_ target file if the latter exists. Thus, the watch becomes invalid.
This behaviour is intended.
Correct me if I'm wrong, people.
Regards,
--
Vladimir
___
busybox mailing l
YES
But, with this solution, it seems that my handler is left waiting for
events after it was told not to expect any anymore.
You mean in your scenario you get event on specified file only once?
--
Vladimir
___
busybox mailing list
bu
>
>
> But, with this solution, it seems that my handler is left waiting for
> events after it was told not to expect any anymore.
>
You mean in your scenario you get event on specified file only once?
--
Vladimir
___
busybox mailing list
busybox@busybox
Will try it later.
But, with this solution, it seems that my handler is left waiting for events
after it was told not to expect any anymore.
Piotr
inotifyd: exec echo 8000hello
Aha. 8000 is IN_IGNORED. We should bitwise AND received event mask with
0x0FFF.
Indeed, if
>
>
> inotifyd: exec echo 8000hello
>
Aha. 8000 is IN_IGNORED. We should bitwise AND received event mask with
0x0FFF.
Indeed, if you move a side file to watched one, the watch should report only
the Delete event.
Then it becomes stale since watched inode does not exist anymore.
Tr
There are two files: hello and hello_tmp. I do:
# mv hello_tmp hello
Result for all events:
inotifyd: exec echo 0400D hello
D hello
inotifyd: exec echo 8000hello
hello
And if only M is specified:
inotifyd: exec echo 8000hello
hello
Regards,
Piot
>
> But, if I ask for M, myhandler is called and the passed event is blank.
Let's check it.
Uncomment the debugging statement after *s = '\0'; and comment out
wait2pid(...);
(In the debugging statement it is necessary to use args[0] instead of
agent).
Compile and try out. What is event mask you
Yes, the event is wrong.
But, if I ask for M, myhandler is called and the passed event is blank.
If I ask for DM, I get D and a blank event.
Don't remember now what happens for all events.
So there is some mystery. If I ask for M and the event is not an M event why is
my handler called?
Piotr
On
> # inotifyd /home/piotr/myhandler /var/tmp/myfiles/data:M
>
> The 'data' file exists. New file 'data_tmp' is created. 'data_tmp' is
> renamed to 'data'.
>
I think you've chosen the wrong event. Filename is just a "tag", it is
inodes that are looked for events. (Correct me if I'm wrong, guys)
Tr
# inotifyd /home/piotr/myhandler /var/tmp/myfiles/data:M
The 'data' file exists. New file 'data_tmp' is created. 'data_tmp' is renamed
to 'data'.
Piotr
No change. Still no M.
Strange enough.
Let me see how you call inotifyd.
--
Vladimir
__
Your example works for me too.
Piotr
> On Friday 14 November 2008 23:02, Piotr Grudzinski wrote:
>> No change. Still no M.
>
> Works for me:
>
> # ./busybox inotifyd echo TODO_config_nommu
> M TODO_config_nommu
>
> (I did "mv TODO_config_nommu TODO_config_nommu.x")
> --
> vda
___
> No change. Still no M.
>
Strange enough.
Let me see how you call inotifyd.
--
Vladimir
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
> Having 11 letters for other events I tried letter 'O' for 'unwrittable
> file is closed' which failed. A zero was
> expected which I find interesting: why one number and eleven letters?
>
0 (zero) stands for "nothing". I presumed closing a read-only file as
"nothing has changed". Thus the nam
On Friday 14 November 2008 23:02, Piotr Grudzinski wrote:
> No change. Still no M.
Works for me:
# ./busybox inotifyd echo TODO_config_nommu
M TODO_config_nommu
(I did "mv TODO_config_nommu TODO_config_nommu.x")
--
vda
___
busybox mailing list
busybox@
On Friday 14 November 2008 23:04, Vladimir Dronnikov wrote:
> > You must dispose of your own zombies, or set SIGCHLD to SIG_IGN.
> > the second is a semi-official Linux extension
>
>
> I'm concerned primarily to Linux.
>
>
> > Setting SIGCHLD to SIG_IGN would make inotifyd to fire-and-forget
>
Having 11 letters for other events I tried letter 'O' for 'unwrittable file is
closed' which failed. A zero was
expected which I find interesting: why one number and eleven letters?
:-)
Piotr
3. Was the number zero intended to be used for the 'unwrittable file is
closed' event?
Didn't ca
>
> You need to say so in help text.
I almost didn't touch inotifyd since it was born. The time has come, since
active users appear.
> Moreover, some users won't like it.
> They might want to get these events in a serialized fashion.
I suppose it is a least surprising behavior.
> No. init s
No change. Still no M.
BR,
Piotr
2. The letter M - for the 'self is moved' event - is never passed to my
agent script; the script runs but there is nothing printable in the 1st
parameter.
I'll take closer a look.
Seems we had classic buffer overflow :)
Will you try attached pat
On Friday 14 November 2008 21:58, Vladimir Dronnikov wrote:
> > 1. Every time my agent script runs, a new zombie process is left behind.
> > The same script runs cleanly with a cron program. (this is not the busybox
> > cron).
> >
>
> A zombie is a terminated process which is not wait()ed by its p
>
> 2. The letter M - for the 'self is moved' event - is never passed to my
>> agent script; the script runs but there is nothing printable in the 1st
>> parameter.
>>
>
> I'll take closer a look.
>
Seems we had classic buffer overflow :)
Will you try attached patch?
> Regards,
> --
> Vladimir
>
>
> Here are my problems with inotifyd applet:
>
Let us take a look.
> 1. Every time my agent script runs, a new zombie process is left behind.
> The same script runs cleanly with a cron program. (this is not the busybox
> cron).
>
A zombie is a terminated process which is not wait()ed by its p
Hi,
I am running busybox 1.12.1 on uClinux (from uClinux.org) on ARM9 nommu system.
Here are my problems with inotifyd applet:
1. Every time my agent script runs, a new zombie process is left behind. The
same script runs cleanly with a cron program. (this is not the busybox cron).
2. The letter
44 matches
Mail list logo
