Bug 203956

Summary: File Watcher plasmoid stops watching files
Product: [Unmaintained] plasma4 Reporter: Malte S. Stretz <mss>
Component: widget-filewatcherAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: honzulak1, kdebugzilla01, markinhos, wonko
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Malte S. Stretz 2009-08-15 15:59:45 UTC
Version:            (using KDE 4.3.0)
OS:                Linux
Installed from:    Ubuntu Packages

The File Watcher plasmoid tends to lose track of file changes.  When this happens, I notice that half of the last line is attached to the previous output and after that, no updates are registered.

The file I watch is generated by a cronjob (each 15 minutes) and has some delay between writes, something like:

date
sleep 10 # data retrieval
for i in $(seq 1 10) do echo line $i
Comment 1 marcos 2009-08-16 21:21:11 UTC
I have a bash script that updates a file each 10 minutes. I verified that the FileWatcher didn't 'recognize' the alteration when the "echo >" is executed (that I use for cleaning the file), but when the "echo >>" is executed, FileWatcher works properly.

I use this script since 4.0.0, and this problem appeared after I updated to 4.3.0 (from debian packages).
Comment 2 Jan Drewes 2009-11-25 15:05:47 UTC
I can confirm this. I use FileWatcher to track /var/log/syslog, and it seems to always just stop when syslog restarts and the old /var/log/syslog gets moved to /var/log/syslog.1, and a new /var/log/syslog is created. The behavior as I would expect it would be to then follow/watch the new /var/log/syslog, instead of just stopping. This used to work before - I am not entirely sure on which KDE, but some 4.X before the one currently shipping with Ubuntu Karmic Koala (9.10).
Comment 3 Wonko 2010-11-12 18:59:03 UTC
I think this behaviour is just normal, you see the same with tail. It normally follows a file, and when it is renamed, it stays the same file, the inode is not changed. So the file watcher works technically correct, it still watches the file. But this is probably seldom useful.

tail has the option --follow=name to change this. I would like the plasmoid to have an option so I can choose between --follow=name and --follow=descriptor behaviour. Or at least to use --follow=name mode, as that's what the majority of users probably expects.
Comment 4 Myriam Schweingruber 2012-05-16 09:37:49 UTC
Is this still an issue with KDE 4.8.3?
Comment 5 Wonko 2012-05-16 10:02:37 UTC
Whoa, it isn't! When I rename the file that is being watched, the playmoid reacts and states that it cannot find the file. Once it is re-created, it is shown again.

So, although I'd still like the option to choose between the two methods (follow by name or by inode), it now does what most people would expect. And I can let it watch my log files directly, instead of mirroring those log files locally with tail --follow=name. Cool!
Comment 6 Myriam Schweingruber 2012-05-16 11:27:59 UTC
Thank you for the fast feedback.
Comment 7 Wonko 2012-05-17 10:58:24 UTC
Sorry, the feedback was _too_ fast. 

I have a file watcher plasmoid watching a local copy of my metalog syslog file /var/log/everything/current, which I generate via a script in .kde/env/, using tail --follow=name. This is my workaround for this bug. After my successful test yesterday, I changed the file to /var/log/everything/current, but now I see it's still watching this file, which has been renamed meanwhile and does not change any more.

But why did my test yesterday work fine? I just did it again, and it seems the plasmoid needs the watched file to disappear for while.

My test was watching /tmp/log which is created like this:
while :; do date >> /tmp/log; sleep 1; done

When I mv /tmp/log /tmp/log.old, the result varies:

- Sometimes, the plasmoid briefly tells me the file has gone, but then picks up the new one. This happened yesterday.
- Sometimes, it keeps watching the renamed file. Even if I delete it, the output just stops then. If I delete the original file, the plasmoid reacts.

I guess the plasmoid (or probably the underlying Qt file watch function) checks the existence of the file every second or so, and if the file is gone at that moment, it will pick up a new one when it comes into existence. But if the file is renamed, and a new one is being created instantly, it will not notice this and just follow the renamed file.

Please reopen.
Comment 8 marcos 2012-05-18 16:38:12 UTC
In my case, it seems solved. 
The loop with (echo $var1 > file; echo $var2 >> file) is working as expected.
The behavior is also ok if the file is removed and then recreated (with touch).

I tested version 4.8.3-1 from archlinux.
Comment 9 Wonko 2012-05-18 17:44:03 UTC
Yes, but if the file is moved, a new file of the same name will not be tracked.

Whatever the intention of this plasmoid is, it is unusable for watching syslog files. Either you lose track when the file gets rotated, or if you let the log file grow and grow, it will become very large, and the plasmoid will use huge amounts of memory then (see bug 256187).
Comment 10 Wonko 2012-11-29 09:18:26 UTC
Can someone re-open this bug? With KDe 4.9.3, this plasmoid is not useful for me, as it cannot track my metalog syslog files which get rotated daily.