I am trying to solve a maddening disk spin up issue and I keep getting pointed to this. I installed it and it seems to run with no errors but it never sees any file activity. I ran mover to copy some files over in both directions and I still never see anything in the file activity page. I know I am setting something up wrong but I cannot figure out what. Eventually file activity stops and I get the inotify upper limit reached error so I get that part but I should see something prior to that correct? I have attached my diagnostics. 

 

Thanks

tower-diagnostics-20200923-1947.zip

22 minutes ago, billbrasky82 said:

trying to solve a maddening disk spin up issue

Your appdata has files on the array.

11 minutes ago, trurl said:

Your appdata has files on the array.

yeah, it was just a bunch of empty folders and a random image or two that I never got around to deleting. I did that but the server is still refusing to keep drives spun down and the activity light is still going nuts. But at least this showed some of the activity I did so I guess I don't need any support for this plugin lol. Thanks!

On 9/19/2020 at 1:26 PM, icemansid said:

/var/log/file.activity.log

wow, great. thanks!

I want to copy the file daily.

Is there a command in can run, to reset this log every day after a copied it?

so a copy a file.activity_DATE.log file, and after that, reset the file with a command

On 10/22/2020 at 9:42 AM, LSL1337 said:

wow, great. thanks!

I want to copy the file daily.

Is there a command in can run, to reset this log every day after a copied it?

so a copy a file.activity_DATE.log file, and after that, reset the file with a command

 

 

Ok, i was going through my syslog, and found it by accident.

 

So if anyone else wants to write this to share for any reason, you can use this very basic script: (via custom scripts daily or whatever)

 

##copy to user share
cp /var/log/file.activity.log /mnt/user/backup/logs/FA/$(date +"%Y-%m-%d__%H-%M")__File_Activity.log
##clear the log
/usr/local/emhttp/plugins/file.activity/scripts/rc.file.activity 'clear' 

## remove logs older than 180 days
find /mnt/user/backup/logs/FA/ -name '*.log' -type f -mtime +180 -exec rm -f {} \; 

 

Edited October 28, 20205 yr by LSL1337

Hello, 

 

I installed this plugin; however, for some reason after a few minutes, it stops. Any ideas? I had everything set to yes. Thanks 

I am re-evaluating my development efforts with Unraid and need to cut back on some plugins that are not providing core functionality in Unraid.  This plugin will be deprecated starting with Unraid 6.9.  This plugin does not provide enough of an enhancement to the Unraid OS and I don't have the time to continue development efforts.  If it's deemed to be a necessary part of Unraid, LT should include the functionality.

2 hours ago, dlandon said:

I am re-evaluating my development efforts with Unraid and need to cut back on some plugins that are not providing core functionality in Unraid.  This plugin will be deprecated starting with Unraid 6.9.  This plugin does not provide enough of an enhancement to the Unraid OS and I don't have the time to continue development efforts.  If it's deemed to be a necessary part of Unraid, LT should include the functionality.

does it work in it's current form on 6.9?

Is there another way to find the information that this plugin provided? Perhaps something manual from the shell? I'm trying to figure out what is spinning up my array disks almost immediately after spinning down.

5 minutes ago, pervel said:

what is spinning up my array disks

Go to Tools-diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. 

37 minutes ago, trurl said:

Go to Tools-diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. 

Thank you. The diagnostics attached was created shortly after I had first forced a spin down and then saw the array spin up.

basse-diagnostics-20201114-1903.zip

I've been debugging for hours now. It very much looks like the disk spin up is caused by docker. Disabling docker completely seems to solve the issue. Now the question is if it is docker itself or some container. The weird thing is that even if I start some containers, see the problem, then stop all containers, the problem does not go away. However, if I disable and then enable docker without starting any containers, the problem is not there.

 

Anyway, I do suspect one particular container: Minio. With that container started, I cannot get the array to spin down even though there should be no activity. But as mentioned above, it's quite confusing what's causing the problem. I'm still on a trial version so I have experimented a lot. That also makes it difficult to figure out what changes cause the issue.

57 minutes ago, pervel said:

disk spin up is caused by docker

That was my first suspicion, but I checked your appdata, system shares are all on cache, and docker.img is in system share.

 

1 hour ago, pervel said:

I do suspect one particular container: Minio. With that container started, I cannot get the array to spin down

If docker is enabled but that container is NOT started, does it spin down?

 

Post your docker run for that container as explained at this very first link in Docker FAQ:

 

8 minutes ago, trurl said:

If docker is enabled but that container is NOT started, does it spin down?

Yes, it seems so. But I have to wait a few minutes after stopping it before spin down will work.

 

9 minutes ago, trurl said:

Post your docker run for that container as explained at this very first link in Docker FAQ:

This is the run command (secret key replaced with stars):

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='Minio' --net='bridge' -e TZ="Europe/Paris" -e HOST_OS="Unraid" -e 'MINIO_ACCESS_KEY'='minio' -e 'MINIO_SECRET_KEY'='*********' -p '9768:9000/tcp' -v '/mnt/user/minio/':'/data':'rw' -v '/mnt/user/appdata/minio':'/root/.minio':'rw' 'minio/minio' server /data
687af9711f4163ed72f99c5c5f8357d385f40b0a5edbb693a52dfe4c3a53ea84

I do wonder if maybe the answer is just to never spin down the disks. That seems to be what some people recommend anyway.

That minio container uses /mnt/user/minio as one of its mappings, and that share has files on both disk1 and cache so it is very likely keeping the array active.

20 hours ago, LSL1337 said:

does it work in it's current form on 6.9?

Yes

I am running the 6.9 beta and fix common problems is bugging me to update this plugin but while I try to it says my unraid version is too high?

 

Any way to make the update go away if it can't be updated?

Is FCP up to date?

10 hours ago, Squid said:

Is FCP up to date?

What is FCP?

 

Far as I know everything is up to date, all the plugins are updated except file activity in the plugin page. I am on beta 30 vs 35 but waiting for some downtime to make that update.

1 hour ago, TexasUnraid said:

What is FCP?

 

13 hours ago, TexasUnraid said:

fix common problems

 

Ah, well it might not of been when I got the message, I updated all the plugins after that but just noticed that the file activity failed to update and assumed I would keep getting bugged.

 

I don't see it in the fix common problems messages now, so that might of been it.

On 11/14/2020 at 10:42 AM, LSL1337 said:

does it work in it's current form on 6.9?

The only incompatibility I can see is it can't track activity on alternate pools. I thought enabling cache might pick it up but no. Otherwise, works just as in 6.8.3.

23 minutes ago, CS01-HS said:

The only incompatibility I can see is it can't track activity on alternate pools. I thought enabling cache might pick it up but no. Otherwise, works just as in 6.8.3.

Correct, it only works currently on cache.  It will need to be upgraded and I'll have a look at that.

My File Activity plugin on 6.9-beta25 has just recently stopped working, though I'm not sure it's *entirely* File Activity's fault.  When I try to start File Activity, it fails with the following error:

inotifywait[9438]: Couldn't watch /mnt/disk2: No such file or directory

Which is fairly unsurprising because I don't *have* a disk2 so I'm not expecting a /mnt/disk2.  However /usr/local/emhttpd/state/disks.ini does contain this entry:

["disk2"]
idx="2"
name="disk2"
device=""
id=""
size="0"
status="DISK_NP"
rotational=""
format="-"
temp="*"
numReads="0"
numWrites="0"
numErrors="0"
type="Data"
color="grey-off"
spindownDelay="-1"
spinupGroup=""
smType=""
deviceSb=""
idSb=""
sizeSb="0"
luksState="0"
comment=""
floor="0"
exportable="no"
fsType="auto"
fsStatus="-"
fsColor="grey-off"
fsSize="0"
fsFree="0"

 

It's not totally clear to me yet where this entry came from (or how to make it go away), but if this is expected Unraid behavior, File Activity should maybe ignore (or gracefully fail to watch) disks in this state.

Would love any pointers anyone has on how to get rid of this weird phantom disk, or why it's here in the first place

1 hour ago, Sammy1Am said:

My File Activity plugin on 6.9-beta25 has just recently stopped working, though I'm not sure it's *entirely* File Activity's fault.  When I try to start File Activity, it fails with the following error:

inotifywait[9438]: Couldn't watch /mnt/disk2: No such file or directory

Which is fairly unsurprising because I don't *have* a disk2 so I'm not expecting a /mnt/disk2.  However /usr/local/emhttpd/state/disks.ini does contain this entry:

["disk2"]
idx="2"
name="disk2"
device=""
id=""
size="0"
status="DISK_NP"
rotational=""
format="-"
temp="*"
numReads="0"
numWrites="0"
numErrors="0"
type="Data"
color="grey-off"
spindownDelay="-1"
spinupGroup=""
smType=""
deviceSb=""
idSb=""
sizeSb="0"
luksState="0"
comment=""
floor="0"
exportable="no"
fsType="auto"
fsStatus="-"
fsColor="grey-off"
fsSize="0"
fsFree="0"

 

It's not totally clear to me yet where this entry came from (or how to make it go away), but if this is expected Unraid behavior, File Activity should maybe ignore (or gracefully fail to watch) disks in this state.

Would love any pointers anyone has on how to get rid of this weird phantom disk, or why it's here in the first place

It's an unassigned slot in the array.  I've made an update that will ignore a non-existent disk.