On 31Dec2020 11:08, Greg Woods <greg@xxxxxxxxxxxxxx> wrote:
>On Wed, Dec 30, 2020 at 11:04 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
>wrote:
>> On Wed, Dec 30, 2020 at 10:12 AM Greg Woods <greg@xxxxxxxxxxxxxx>
>> 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@xxxxxxxxxx>
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
