MantisBT - Issues

0000470: Root receives undocumented IN_IGNORED event

Sat, 21 Aug 2010 16:37:44 +0200

Root, via /etc/incron.d/foo, received an IN_IGNORED event when monitoring file foo when emacs (I believe) deleted foo~ in a second editing session after, in an initial editing session, changing the name of foo to foo~ and leaving it as a backup file.

The identical incrontab entry in the user's incrontab

/home/kop/tmp/incron/foo IN_MODIFY,IN_ATTRIB,IN_CLOSE_WRITE logger -t rootincrontab "Received event $%"

received no such event. (AFAICT)

In any case IN_IGNORED is not documented in the incrontab(5) man page.

0000469: Incron needs a new symbol to track files by path

Sat, 21 Aug 2010 16:37:21 +0200

Incron exhibits somewhat inconsistent behavior in that it tracks files by inode (I assume) but these files are specified by path in the incrontab. So, if you delete a file and re-create it, as some commonly used editors do as part of the editing process, the file is no longer tracked -- until incrond is restarted or
(I assume) the incrontab file is modified at which point the (new) file is again tracked.
This 'impedance mismatch' is a bit odd.

I assume this is the intended design. It is the behavior I observe.

If nothing else a note of this issue should be made in the documentation.

It would be nice if incron had a new symbol, say IN_TRACK_PATH, that keeps the tracking associated with the pathname given in the config file. I assume this could be done by monitoring the parent directory for changes and watching for the file name to come into existence, the name of the file to change, etc.

I would think that the desire to track changes to a file that exists in a particular filesystem location is rather common. Absent this feature it's up to the user to repeatedly script such things.

Note that such a change alters the meaning of existing symbols, e.g., changing the file name would be equivalent to deleting the file, etc.
I don't know whether it makes sense to re-use the existing symbols in this new context or to come up with entirely new ones.

0000468: incron logs command to execute but command is not executing

Sat, 21 Aug 2010 16:37:03 +0200

Attaching usage log, for reference.

# empting "log"

andres@terminus:~$ > /tmp/ic.log

# verifying incrontab

andres@terminus:~$ incrontab -l
/home/andres/maps IN_MODIFY /usr/bin/make -C $@ > /tmp/ic.log 2>&1

# modifying file

andres@terminus:~$ cat > maps/all.dot < > digraph
> {
> nod
> }
>

# validating date

andres@terminus:~$ date
Tue Jun 1 10:01:39 COT 2010

# verifying syslog, the commands is "executed"

andres@terminus:~$ su -c "tail -5 /var/log/syslog"
Password:
Jun 1 10:01:33 terminus incrond[5924]: (andres) CMD (/usr/bin/make -C /home/and
res/maps > /tmp/ic.log 2>&1)
Jun 1 10:01:33 terminus incrond[5924]: (andres) CMD (/usr/bin/make -C /home/and
res/maps > /tmp/ic.log 2>&1)

# verifying Makefile

andres@terminus:~$ cat maps/Makefile
all: all.png

all.png: all.dot
dot -Tpng $< > $@

# log is empty

andres@terminus:~$ cat /tmp/ic.log

# outfile is outdated

andres@terminus:~$ ls -l maps/all.png
-rw-r--r-- 1 andres andres 12457 2010-06-01 09:58 maps/all.png

# the command works

andres@terminus:~$ /usr/bin/make -C /home/andres/maps > /tmp/ic.log 2>&1

# outfile is updated

andres@terminus:~$ ls -l maps/all.png
-rw-r--r-- 1 andres andres 133 2010-06-01 10:04 maps/all.png

# "log" is logging

andres@terminus:~$ cat /tmp/ic.log
make: Entering directory `/home/andres/maps'
dot -Tpng all.dot > all.png
make: Leaving directory `/home/andres/maps'

andres@terminus:~$ date
Tue Jun 1 10:05:11 COT 2010

# weird

0000397: duplicate events firing

Fri, 02 Jul 2010 14:23:34 +0200

incrond: 0.5.8
Kernel 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008 i686 i686 i386 GNU/Linux

I cannot explain this one.

incrond is reporting multiple events where events only happened (AFAIK) one time. This has been confounding as, if I trigger file operations against IN_CLOSE_WRITE, sometimes these operations are being launched twice (sometimes three times) and are therefore clobbering one another.

Details below.

0000449: incrontab(1) mangles comments in incrontab(5)

Sat, 05 Jun 2010 23:46:43 +0200

incrontab(1) mangles comments in incrontab(5): it changes the first word on every comment line to "0". For example, if I run incrontab and create a file with the following comment lines:

# Only put 1 space between fields 2 and 3! Additional whitespace will be
# assumed to be part of field 3, causing the command to fail!

then incrontab -l shows that I have the following incrontab file:

# 0 put 1 space between fields 2 and 3! Additional whitespace will be
# 0 to be part of field 3, causing the command to fail!

To clarify, this doesn't just matter because of comments, although they're important. It also means that I can't temporarily disable a line by commenting it out-- if I do, then incrontab will replace the path entry by a 0.

0000461: Allow line wrapping

Sat, 05 Jun 2010 23:43:20 +0200

It would be good to have possibility to wrap lines in incron tables (eg. using the backslash character). Very long lines are poorly readable.

0000459: Get cookie when IN_MOVE* event is thrown

Fri, 21 May 2010 01:02:03 +0200

Hello,

Don't be to cruel, I have never coded in c++ but I made a patch that allow me to get the cookie when an IN_MOVED_TO, IN_MOVED_FROM or IN_MOVE events are thrown.
It replace the $§ parameter on the entry line.
I don't know if it's the best symbol for that and if someone is interested in it, but it's avoid me real pain to track some mv in folders.

Hope you will enjoy it and I am open to remarks

JC Passard

0000456: Mailing list subscription fails

Mon, 26 Apr 2010 22:22:52 +0200

When I tried to subscribe to the mailing list, my message was rejected as SPAM.

Below is the error message (I've removed my domain name since this issue will be public).

I used the email address associated with this Mantis account.

0000457: Inotify maintains list of InotifyWatch objects that could be dead

Mon, 26 Apr 2010 22:05:24 +0200

In the example.cpp, only one watch is added, and remains in-scope during the whole process. However, if I want to add more than one watch, and do so in a for-loop, the watch goes out of scope, and thus Inotify::GetWatch() references a dead object.

Attached is an example of what I'm talking about, with some output for when InotifyWatch is constructed/destructed.

And since InotifyWatch has no default constructor, there's really no way to create an array of InotifyWatch* that will outlast the Inotify object, and thus remain alive.

My thought would be to make a copy of the InotifyWatch* when it is added, and then make sure to clean up when RemoveAll() is executed. However, since this code has been around for a long time, I'm guessing there's a reason you didn't do it that way, and I'd love to hear why.

Also, you've got two Inotify::Add() methods, one for a reference, and one for a pointer, thereby implying that object lifetime is handled differently depending on which method is used.

0000455: Minimizing to the systen tray

Sat, 27 Mar 2010 13:41:47 +0100

Try to find a platform independent way how to implement minimizing to the system tray.

0000454: package as rpm

Tue, 23 Mar 2010 23:35:36 +0100

Attached is a .spec file to package inotify-cxx as an rpm. The .spec is mostly conformant to current Fedora packaging guidelines.

currently requires the namespace and cmake patch. They can be removed if they are applied into upstream inotify-cxx.

0000453: build as library

Tue, 23 Mar 2010 23:35:09 +0100

We have several programs which use inotify-cxx. So building and using inotify-cxx as a library has several advandages:

- if a new version of inotify-cxx comes out, we have to update only once
- if the shared library is used and several programs using it run at once, the lib is only loaded once into the memory
- it is possible to package it and submit this package to distributions like Fedora, Debian, Ubuntu,...

A good library on Linux is usually encompanied by a pkgconfig file. With it it's more conveniant for the user to include the library into a project. So the user does not have to fiddle with the correct library- or include-paths.

Attached are two files:
CMakeLists.txt: for controlling build and install with cmake
inotify-cxx.pc.in: to serve as stub for the pkgconfig file

Just copy these files into the root dir of inotify-cxx. Then call

mkdir build # build in a separate builddir
cd build
cmake ..
make

To copy the lib into /usr/local/lib and the header to /usr/local/include etc.:
make install

If you want to copy to /usr... instead call it like this:

cmake -DCMAKE_INSTALL_PREFIX="/usr" ..

0000452: use namespace

Tue, 23 Mar 2010 23:34:29 +0100

if inotify-cxx is used together with other code or libraries, the other code may happen to use a variable, classname, typedef,... with the same name as inotify-cxx. This results in a name clash and lots of trouble.

The solution is to embed each lib in it's own namespace.

I have attached a patch which implements this.

If you don't expect any name clashes, you can write

using namespace inotify;

at the top of your program and everything works as before.

0000450: Running as an applet

Wed, 17 Feb 2010 18:11:23 +0100

Implement possibility to run LWTT as an applet (e.g. for including into web pages). This solution should store its data on the server where it is running from.

0000120: Recursive watches (for monitoring subtrees)

Sun, 24 Jan 2010 23:08:43 +0100

It's not a bad idea to implement watches for monitoring whole subtrees. Since inotify doesn't support this feature it must be implemented on the application layer.

0000447: build fixes for gcc4.4

Fri, 25 Dec 2009 17:53:56 +0100

We've been carrying the attached patch for a while now in Fedora, would you mind including it?

0000448: incron wish list for "normal" users :)

Fri, 25 Dec 2009 17:53:35 +0100

I report it to Fedoras Bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=549010 [^] ), but I was referred here. Than there slightly more detailed opinion and request for improvements:

- allow comments in incrontab files (when they must start on first column
should be fine). This should be usefull e.g. for templates possibility, events
list for these not quite familiar with inotify,...

- incron documentation should be more accurately/detailed

- allow along with as separator between
fields for more comprehensible human view. I not tried it, but probably path field can be escaped, when it contains certain special chars, then it should not be problem.

- when manually editing system tables, editors are frequenly configured for
leaving original file as backup with tilde appended to name. But incrond take
this backups as its valid files, what is some confusing and different from
majority of other programs behavior. I think, optimal is consider only files
with given suffix (e.g. ".conf", as it is in apache and others). In this manner should be reduce couple event switching (as I see in /var/log/cron) after editing system tables, which probably arises when edited table is renamed/moved/etc. I'm not sure, when it may be cause of it (incrond itself cannot be quilty for), but I have in my /var/log/messages oops like:

Dec 20 05:20:03 franta kernel: ------------[ cut here ]------------
Dec 20 05:20:03 franta kernel: WARNING: at fs/notify/inotify/inotify_fsnotify.c:129 idr_callback+0x32/0x56() (Not tainted)
Dec 20 05:20:03 franta kernel: Hardware name: P5E-VM HDMI
Dec 20 05:20:03 franta kernel: inotify closing but id=0 for entry=ed0b8900 in group=d657d600 still in idr. Probably leaking memory
Dec 20 05:20:03 franta kernel: Modules linked in: bluetooth rfkill hfs hfsplus nls_utf8 fuse ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs autofs4 nfs lockd fscache nfs_acl auth_rpcgss sunrpc bridge stp llc cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm uinput snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer firewire_ohci snd firewire_core crc_itu_t iTCO_wdt soundcore iTCO_vendor_support asus_atk0110 i2c_i801 snd_page_alloc atl1 serio_raw e100 mii ata_generic pata_acpi pata_jmicron i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Dec 20 05:20:03 franta kernel: Pid: 7426, comm: incrond Not tainted 2.6.31.6-162.fc12.i686.PAE #1
Dec 20 05:20:03 franta kernel: Call Trace:
Dec 20 05:20:03 franta kernel: [] warn_slowpath_common+0x70/0x87
Dec 20 05:20:03 franta kernel: [] ? idr_callback+0x32/0x56
Dec 20 05:20:03 franta kernel: [] warn_slowpath_fmt+0x29/0x2c
Dec 20 05:20:03 franta kernel: [] idr_callback+0x32/0x56
Dec 20 05:20:03 franta kernel: [] idr_for_each+0x5c/0x97
Dec 20 05:20:03 franta kernel: [] ? idr_callback+0x0/0x56
Dec 20 05:20:03 franta kernel: [] ? fsnotify_put_event+0x48/0x4b
Dec 20 05:20:03 franta kernel: [] inotify_free_group_priv+0x1a/0x2b
Dec 20 05:20:03 franta kernel: [] fsnotify_final_destroy_group+0x1e/0x28
Dec 20 05:20:03 franta kernel: [] fsnotify_put_group+0x75/0x78
Dec 20 05:20:03 franta kernel: [] inotify_release+0x1e/0x28
Dec 20 05:20:03 franta kernel: [] __fput+0xed/0x184
Dec 20 05:20:03 franta kernel: [] fput+0x18/0x1a
Dec 20 05:20:03 franta kernel: [] filp_close+0x56/0x60
Dec 20 05:20:03 franta kernel: [] put_files_struct+0x5d/0xa1
Dec 20 05:20:03 franta kernel: [] exit_files+0x33/0x37
Dec 20 05:20:03 franta kernel: [] do_exit+0x1cb/0x5da
Dec 20 05:20:03 franta kernel: [] do_group_exit+0x66/0x8d
Dec 20 05:20:03 franta kernel: [] sys_exit_group+0x18/0x1c
Dec 20 05:20:03 franta kernel: [] sysenter_do_call+0x12/0x28
Dec 20 05:20:03 franta kernel: ---[ end trace bf2ba6f50ae90f71 ]---
Dec 20 05:20:03 franta kernel: entry->group=(null) inode=(null) wd=1024
Dec 20 05:20:08 franta abrt: Kerneloops: Reported 1 kernel oopses to Abrt

and incrond ends with "IN_IGNORED" flag for certains events and there isn't (I think) other chance to return to normal behavior than restart it. Absolutely inacceptable for productional usage, but as it is rather kernel bug, still uncorrected (F12 2.6.31.6-166.fc12.i686.PAE kernel), why shall incrond uselessly provoke kernel for this?
And as for comments in incrotabs, I can imagine as usefull e.g. some sort an README in /etc/incron.d/ which is usefull for admins, but is ignored by incrond.

0000446: Create support for shell-like behavior in commands

Wed, 09 Dec 2009 22:23:49 +0100

The event rules should allow to write "shell-like" commands, ie. with logical operators, pipes and other such features.

0000445: Introduce a limit for command parallelism

Wed, 09 Dec 2009 16:19:08 +0100

There is a problem (reported by Thomas Güttler) if many events occur in a small time period. It forks many child processes and system's load may be of tens or even hundreds. It may lead to massive context switching, physical memory shortage or other unpleasant effect which drastically reduce system performance. There should be an adjustable limit (or more limits, e.g. global one, per-user ones and per-watch ones) to enforce to have only a "rational" number of processes. If more commands to be invoked they will be deferred (enqueued) and started later.

0000431: incron doesnt process symlinks in /etc/incron.d/

Sun, 01 Nov 2009 18:08:29 +0100

the load_tables() function only processes regular files and ignores symlinks. so if a valid file is at like /etc/foo/ and gets added by:
ln -s /etc/foo/moo /etc/incron.d/moo

the file never gets added

0000424: support comments and other whitespace in incrontab files

Thu, 15 Oct 2009 20:58:15 +0200

Please improve your string parsing/handling to allow:
1. Allow tabs as column separators.
2. Allow comments starting with (whitespace)# or # at the start of line.

0000173: allow comments in incrontab files

Fri, 09 Oct 2009 15:35:24 +0200

incrontab(1) removes any #-comment lines from the file after editing. It would be nice if comments were preserved.

0000420: Load rule tables differentially

Wed, 30 Sep 2009 17:10:50 +0200

The current implementation drops all watches when reloading a rule table. This behavior may be unacceptable in some cases. It should be modified to only add/remove/change those rules that have been really added/removed/changed.

0000417: incrontab prints to stderr instead of stdout

Tue, 22 Sep 2009 19:44:04 +0200

When importing a file with the "incrontab " syntax, the output is written on stderr even when no erro occurs. The text "copying table from file ''" should be printed on stdout.

0000412: Typo: the word editting should be editing

Sun, 26 Jul 2009 01:58:11 +0200

A patch which fix this issue is attached.