All recordings in use

[MymsMan]

I was surprised to find that all my decryption and detectads processes today were failing with file 'in use' errors

It turns out that one of my network shares had gone offline and for some reason scanmounts hadn't noticed or unmounted the share

Running lsof manually I saw: that it was running Very slowly and returning

lsof -X -Fn "/mnt/hd2/My Video/Impossible/Impossible_20240202_1300.ts"
lsof: WARNING: can't stat() cifs file system /media/[Homerun]
      Output information may be incomplete.

The Warning message causes the [system inuse] function to think that all files are inuse

Problems to investigate:

• Why would LSOF care about the status of a network drive when given a specific path to check?
• Why is LSOF so slow to respond?
• Why didn't scanmounts unmount the drive?

Stopping [system inuse] returning "in use" is the easy part - a one line change Think again that doesn't work

proc {system inuse} {file} {
    if {![file exists $file]} { return 0 }
    set op [exec /mod/webif/lib/bin/lsof -X -Fn $file 2>@1 | grep $file]
    switch -glob -- $op {
        "" -
        "*status error*" { return 0 }
    }
    return 1
}

 

[/df]

man lsof reveals various parameters that might be relevant:

...
       -b       causes  lsof  to  avoid  kernel  functions  that might block -
                lstat(2), readlink(2), and stat(2).
...
       -f ...
                ...
                When  -f  is specified by itself, all path name arguments will
                be taken to be simple files.  Thus, for example,  the  ``-f --
                /''  arguments direct lsof to search for open files with a `/'
                path name, not all open files in the `/' (root) file system.
...
       -S [t]   specifies  an optional time-out seconds value for kernel func‐
                tions - lstat(2), readlink(2), and stat(2) - that might other‐
                wise  deadlock.   The  minimum for t is two; the default, fif‐
                teen; when no value is specified, the default is used.
...

 

[prpr]

set op [exec /mod/webif/lib/bin/lsof -X -Fn $file 2>@1 | grep $file]

There's already a 2>&1 in /mod/webif/lib/bin/lsof so the 2>@1 seems superfluous (do I presume @ is a typo?)

 

[MymsMan]

The lsof -w option does the trick for suppressing the warning messages and I discovered that because I am using [] in my mount folder names the grep in scanmounts was treating the name as a regex rather than a simple text match and failing, adding a -F to grep should fix that and I will test if that successfully unmounts the drive.

I don't think @Drutt is a actively maintaining his packages any more so we will need to work out the best way to get any update to network-shares-automount into the repository

 

[/df]

The package comprises only scripts, so ingesting it is no problem, as long as the author doesn't mind.

 

[MymsMan]

man lsof reveals various parameters that might be relevant:

...
       -b       causes  lsof  to  avoid  kernel  functions  that might block -
                lstat(2), readlink(2), and stat(2).
...
       -f ...
                ...
                When  -f  is specified by itself, all path name arguments will
                be taken to be simple files.  Thus, for example,  the  ``-f --
                /''  arguments direct lsof to search for open files with a `/'
                path name, not all open files in the `/' (root) file system.
...
       -S [t]   specifies  an optional time-out seconds value for kernel func‐
                tions - lstat(2), readlink(2), and stat(2) - that might other‐
                wise  deadlock.   The  minimum for t is two; the default, fif‐
                teen; when no value is specified, the default is used.
...B

I did try the options suggested but they seemed to have no good effect but thanks for suggestions
-b causes response

lsof: status error on It'll Be Alright on the Night_20240203_2103.ts: Resource temporarily unavailable

whether the file is inuse or not so not helpful
-f had no noticeable affect on performance
-s 2 also had no noticeable affect on performance
I am seeing about .5 sec when network share is connected and 10s when it isn't

There's already a 2>&1 in /mod/webif/lib/bin/lsof so the 2>@1 seems superfluous (do I presume @ is a typo?)

I hadn't actually noticed that the path wasn't a plain /mod/bin/lsof

The -w option does what is needed without the need for grep

If will send a pm to @Drutt to check whether he is OK with me making changes, I have also added timestamps to log messages

 

[prpr]

we will need to work out the best way to get any update to network-shares-automount into the repository

I can do that.

If will send a pm to @Drutt to check whether he is OK with me making changes, I have also added timestamps to log messages

I ran scanmounts through shellcheck.net and it complained about several things, so it's probably worth fixing those too.

 

[MymsMan]

I can do that.

I ran scanmounts through shellcheck.net and it complained about several things, so it's probably worth fixing those too.

Updated package attached and repository created on git,
I have also created a Pull request for webif to fix the system inuse function - though it might be better to add the flag to /mod/webif/lib/bin/lsof so that it covers more lsof uses.

I have not include the shellcheck suggestions because:

• I haven't heard back from @Drutt and don't want to make major changes
• It is more work than I want to undertake
• If it aint broke dont fix it!

 

[/df]

Resolving the shellcheck diagnostics probably won't fix anything except a nagging feeling that there is shell code with known problematic constructs. Some of the diagnostics seem fair and the actual suggestions seem mostly OK. The SC2010 issues (ls -1 | grep ..., no suggestion) would need a bit of thought or to be marked # shellcheck disable.