8 hours ago, dlandon said:

I assume you only want to look at certain shares or disks?

Yes, exclude /mnt/docker for example and others.

Or, look at certain shares or disks.

4 minutes ago, Revan335 said:

Yes, exclude /mnt/docker for example and others.

Or, look at certain shares or disks.

The plugin automatically ignores appdata, syslogs, and system.

 

18 minutes ago, dlandon said:

The plugin automatically ignores appdata, syslogs, and system.

Can you add /mnt/user/docker and /mnt/cache/docker/?

 

The other Points are for future released or ideas.

12 minutes ago, Revan335 said:

 

Can you add /mnt/user/docker and /mnt/cache/docker/?

 

The other Points are for future released or ideas.

I can add the 'docker' share.

Many Thanks for the Update!

 

I became this by starting the Logging?

The Mobile Editor have no Codeblock or others, sorry.🤔😞

 

"

Nov 25 00:21:39 Raster ool www[28174]: /usr/local/emhttp/plugins/file.activity/scripts/rc.file.activity 'start'

Nov 25 00:21:39 Raster file.activity: Starting File Activity

Nov 25 00:21:39 Raster file.activity: File Activity inotify starting

Nov 25 00:21:39 Raster inotifywait[22928]: Setting up watches. Beware: since -r was given, this may take a while!

Nov 25 00:21:58 Raster inotifywait[22928]: Failed to watch /mnt/cache; upper limit on inotify watches reached!

Nov 25 00:21:58 Raster inotifywait[22928]: Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'.

Nov 25 00:21:58 Raster file.activity: File Activity inotify exiting

"

Edited November 24, 20241 yr by Revan335

1 hour ago, Revan335 said:

Many Thanks for the Update!

 

I became this by starting the Logging?

The Mobile Editor have no Codeblock or others, sorry.🤔😞

 

"

Nov 25 00:21:39 Raster ool www[28174]: /usr/local/emhttp/plugins/file.activity/scripts/rc.file.activity 'start'

Nov 25 00:21:39 Raster file.activity: Starting File Activity

Nov 25 00:21:39 Raster file.activity: File Activity inotify starting

Nov 25 00:21:39 Raster inotifywait[22928]: Setting up watches. Beware: since -r was given, this may take a while!

Nov 25 00:21:58 Raster inotifywait[22928]: Failed to watch /mnt/cache; upper limit on inotify watches reached!

Nov 25 00:21:58 Raster inotifywait[22928]: Please increase the amount of inotify watches allowed per user via `/proc/sys/fs/inotify/max_user_watches'.

Nov 25 00:21:58 Raster file.activity: File Activity inotify exiting

"

You can eliminate the cache and pool disks from the file activity, or install the Tips and Tweaks plugin and increase the inotify watches.

The inotify user watches are now adjusted if there aren't enough when the plugin is started.  This is in the latest release.  This should stop the inotify start failure when there aren't enough user watches.

Hello, was recommended to try this tool out to view why my array keeps spinning up when there should be no activity. i notice the status always says "stopped" even after starting it. viewing the share or disk activity and starting it behaves the same. 

3 minutes ago, Clayton said:

Hello, was recommended to try this tool out to view why my array keeps spinning up when there should be no activity. i notice the status always says "stopped" even after starting it. viewing the share or disk activity and starting it behaves the same. 

Post diagnostics.

I seem to have fixed it. i was on Unraid 6.12.13 and I upgraded to 6.12.14. after the reboot the plugin started running. now the fun part. Thanks anyway!

Edited December 22, 20241 yr by Clayton

On 11/25/2024 at 6:44 PM, dlandon said:

The inotify user watches are now adjusted if there aren't enough when Tips and Tweks is started.  This is in the latest release.  This should stop the inotify start failure when there aren't enough user watches.

The November 25 change has caused my array start to take 35 minutes longer than it used to.  I had not noticed it until now as I did not reboot my server or bring the array down then up.  The problem code is this:

 

# Loop through each mount point in the file
                while IFS= read -r mount_point; do
                        if [ -d "$mount_point" ]; then
                                # Count directories in the mount point
                                count=$(find "$mount_point" -type d 2>/dev/null | wc -l)
                                dir_count=$((dir_count + count))
                        fi
                done < "$disks_file"

 

The above creates a series of 'find' commands on each of the drives.  On my array, this takes 34 minutes.  What happens at startup is that /mnt/cache and /mnt/user are 'up', but until the above code finishes, samba shares are not available to clients (the webgui also pauses if the array start was done via the gui).

 

This code is a good idea, but given the above problem it should be included as an option that is by default disabled.

Edited January 16, 20251 yr by tcharron

4 hours ago, tcharron said:

This code is a good idea, but given the above problem it should be included as an option that is by default disabled.

I'll make a change to do this in the background, but honestly, having File Activity always enabled is not the way the FIle Activity plugin was intended to be used.  It's good for figuring out issues with excess activity and disk spin up concerns, but it isn't something that needs to be always enabled  After a restart, you can go to the File Activity page and start it, use it for a while and then stop it.

 

It may also help if you have the cache_dirs plugin installed.

7 hours ago, dlandon said:

I'll make a change to do this in the background, but honestly, having File Activity always enabled is not the way the FIle Activity plugin was intended to be used.  It's good for figuring out issues with excess activity and disk spin up concerns, but it isn't something that needs to be always enabled  After a restart, you can go to the File Activity page and start it, use it for a while and then stop it.

 

It may also help if you have the cache_dirs plugin installed.

You're right - I will just disable it until I need it.  However, I think that whenever I do go to use it down the road, it will still cause a long pause while it counts directories.

 

I had removed cache_dirs many years ago - I see that you've improved it since then and I will install again.

6 hours ago, tcharron said:

You're right - I will just disable it until I need it.  However, I think that whenever I do go to use it down the road, it will still cause a long pause while it counts directories.

 

I had removed cache_dirs many years ago - I see that you've improved it since then and I will install again.

A fix is in the next release.

After the update i found a file called "dead.letter" at the /root dir

 

Starting File Activity...
/usr/local/emhttp/plugins/file.activity/scripts/rc.file.activity: line 6: /tmp/file.activity/file.activity.disks: No such file or directory

 

4 minutes ago, Mainfrezzer said:

After the update i found a file called "dead.letter" at the /root dir

 

Starting File Activity...
/usr/local/emhttp/plugins/file.activity/scripts/rc.file.activity: line 6: /tmp/file.activity/file.activity.disks: No such file or directory

 

Post diagnostics.

29 minutes ago, dlandon said:

Post diagnostics.

magnon-box-diagnostics-20250119-0850.zip



perfect timing for that, since that file is just 5 mins older than the diag.

1 hour ago, Mainfrezzer said:

magnon-box-diagnostics-20250119-0850.zip



perfect timing for that, since that file is just 5 mins older than the diag.

Update File Activity.

I'm guessing I'm missing something......but once starting the File Activity plugin, should something display on the screen or does all the activity write to a log. I've let the service run for long periods of time and never seen anything written to screen for disk or share activity. I have all 3 options set to yes for tracking. 

 

Thanks!

 

Edit:   I'm only seeing this issue on 6.12.15. My 7.0 server works just fine.

 

Edited March 1, 20251 yr by jmbailey2000

This plugin has started to eat my CPU and causes PHP errors..

Not really sure why?

The server is doing some nzbget processing but more than 8GB ram free available. 

 

moulin-rouge-diagnostics-20250302-2303.zip

Edited March 2, 20251 yr by dopeytree

On 2/28/2025 at 6:06 PM, jmbailey2000 said:

I'm guessing I'm missing something......but once starting the File Activity plugin, should something display on the screen or does all the activity write to a log. I've let the service run for long periods of time and never seen anything written to screen for disk or share activity. I have all 3 options set to yes for tracking. 

 

Thanks!

 

Edit:   I'm only seeing this issue on 6.12.15. My 7.0 server works just fine.

 

The activity is logged and can be seen on the share and disk page organized by share or disk depending on the page.  Be sure the 'Status' in the upper right corner shows 'Running'.  If you still can't get it working, post your diagnostics.

13 hours ago, dopeytree said:

This plugin has started to eat my CPU and causes PHP errors..

The plugin does nothing but set up inotify monitoiring on the files.  I have no idea how that can cause high CPU usage unless you are monitoring the nzbget activity.  You should't monitor that activity.

Just had same issue, turned file activity on last night for the first time in ages
This morning it was just hammering the CPU to the point i almost couldnt do anything 
Managed to kill inotifywait and then do a graceful reboot

On 9/14/2019 at 12:06 PM, dlandon said:

Next time take a look at the log and see if it will tell you if there is a problem - It will.  Just posting that it doesn't work is not very productive and a waste of everyone's time.

I understand your point as a dev. But you could formulate that as in "to be able to help or debug, I need specifics. I would be good to tell us exactly what was not working as you expected".

And as a rule of thumb, remember that for most people "does not work" usually means "does not work as advertised". This plugin aims at showing us file activity. I would be 90% ready to bet that what he meant was that no file activity was showing for him in the Web UI.

 

The tone of your reply certainly discouraged the original poster to reply, and it would most probably set quite a few others off too. I'd love for this community to avoid going the "TrueNAS" way and discourage new people to contribute

On 3/6/2025 at 12:08 AM, macmanluke said:

Just had same issue, turned file activity on last night for the first time in ages
This morning it was just hammering the CPU to the point i almost couldnt do anything 
Managed to kill inotifywait and then do a graceful reboot

 

Had a similar issue. On Unraid 7.0.1, the file activity plugin seems to be taking a lot of time to really start monitoring, then ends up using more and more memory and CPU cycles, up to the point of the system being "frozen" or almost and every single command or action on the web UI takes forever, and many failing due to timeout. Removing the plugin solved all my issues.

Yes I do have intensive file activity at the moment (installing a second server as backup and transferring almost everything to it), but if I can't monitor that activity, then the plugin does not have any use for me.

I ended up using a custom user script with rsync and create my own logs. At least if and when something happens, I can trace things back now.