On 31Dec2020 11:08, Greg Woods <greg(a)gregandeva.net> wrote:
On Wed, Dec 30, 2020 at 11:04 PM Chris Murphy
<lists(a)colorremedies.com>
wrote:
> On Wed, Dec 30, 2020 at 10:12 AM Greg Woods <greg(a)gregandeva.net>
> wrote:
> > pub.automount: Got automount request for /pub, triggered by 242640
> (PT3122): 1 Time(s)
> >
> > I want to determine why this is happening, because the drive containing
> /pub (on a different machine mounted via NFS) is spun down when idle, and
> these events are likely causing it to spin up. My understanding is that the
> part inside the parentheses is the command name of the process that
> triggered it, but I don't know what the "PT" syntax means.
> >
>
> One of those should be PID.
>
Yes. The format is "Got automount request for /pub, triggered by #PID#
(#command#): 1 Time(s)
[...]
The problem here is that, by the time I see one of these entries and
investigate, the PID is for a process that is long gone, and I'm not
getting any useful info about what command is triggering this.
Had you considered something like this (untested, and needs work):
tail -F /var/log/messages \
| while read -r line
do
case "$line" in
*'Got automount request for /pub, triggered by '*)
... extract the PID from $Line, do a "ps axf" and locate the
process and its ancestors, write to log ...
;;
esac
done
There's a few things to note here:
- might be the wrong log filename
- "tail -f" and "tail -F" (reopen the file if it gets replaced, eg by
logrotate) have unbuffered output, getting timely response
- I'm using the shell to read line by line, again to act immediately
- filtering the "tail" with awk or something would buffer the awk
output, meaning response gets delayed (likely until after PID is gone)
Also, regarding your /pub automount: if you make the export from the
server cross mounts (use the "crossmnt" option in /etc/exports) then you
could make /pub itself be a small directory on some always spun up disc
on the server eg / but put the _contents_ lower down mounted from other
spun down discs. If you use bind mounts into /pub on the server you
don't need to rearrange the source data.
Doing that may isolate the spun down drives from /pub itself, thus
deferring spin up until something genuinely tried to access the data in
the spin down subdirectories.
Cheers,
Cameron Simpson <cs(a)cskk.id.au>