howeyc/fsnotify

linux ionotify goes into infinite loop on tmpfs

Closed this issue · 3 comments

Hello,

This issue is a little hard to report as it is quite specific. I run /tmp on a tmpfs and using the example code in this package it appears to go into an infinite loop

watching, for example, /home/dfc, then touching /home/dfc/t generates the usual

lucky(~/devel/src/watcher) % go run watcher.go
2012/04/07 19:03:36 event: "/home/dfc/t": CREATE
2012/04/07 19:03:36 event: "/home/dfc/t": MODIFY

watching /tmp as a tmpfs gives

lucky(~/devel/src/watcher) % go run watcher.go 2>&1 | head -n20
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vteAA4WBW": MODIFY
2012/04/07 19:04:39 event: "/tmp/vte763WBW": MODIFY

I'm not sure it this is something specific to my installation (ubuntu 11.10 / amd64)

Could it be you are using a terminal that uses libvte? I think libvte stores your scrollback buffer into /tmp files. As you watch tmp, your scrollback buffer changes, then /tmp files get modified, then your scrollback buffer changes, .....

http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html

Maybe redirect both stdout and stderror to /dev/null and see if it still happens?

I think there is a fair chance that is happening. Thank you for doing that detective work.

On 08/04/2012, at 4:30, Chris Howeyreply@reply.github.com wrote:

Could it be you are using a terminal that uses libvte? I think libvte stores your scrollback buffer into /tmp files. As you watch tmp, your scrollback buffer changes, then /tmp files get modified, then your scrollback buffer changes, .....

http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html

Maybe redirect both stdout and stderror to /dev/null and see if it still happens?


Reply to this email directly or view it on GitHub:
#2 (comment)

Indeed you were correct. gnome-terminal does leave some unlinked files in /tmp which correspond to the entries I was seeing. This also explains why when piping to 2>&1 | less, they did not show up.

lucky(~/devel/src/watcher) % lsof -p 1818 | grep deleted
gnome-ter 1818 dfc 19u REG 0,17 34643 13876 /tmp/vteC14UBW (deleted)
gnome-ter 1818 dfc 20u REG 0,17 5840 13877 /tmp/vteUW4UBW (deleted)
gnome-ter 1818 dfc 21u REG 0,17 1648 13878 /tmp/vte6CNVBW (deleted)
gnome-ter 1818 dfc 22u REG 0,17 441 26029 /tmp/vtePK1VBW (deleted)
gnome-ter 1818 dfc 23u REG 0,17 48 26030 /tmp/vteHO1VBW (deleted)
gnome-ter 1818 dfc 24u REG 0,17 70015 26359 /tmp/vteAA4WBW (deleted)

Thank you again.