On Thursday, 13 February 2020 01:09:20 GMT Roger Heflin wrote:
> It may be the pwd command doing it. It works like this:
>
> if something runs pwd when its cwd is under say /var/log then pwd goes
> through all files in /var/log until it finds .. then it goes up a
> directory and repeats, until it gets to /.
>
> Assuming that is the case your solution would be expected to work, if
> you put it under /mnt/backups then any other pwd anywhere under mnt
> may also cause the spinup. On nfs mounts an nfs mount that is hanging
> of say /mnt/host1 can hang everything else in /mnt even coming from
> other responding hosts. the trick there is to
> /mnt/host1/host1mntpoint and put each separate host in a separate top
> level directory to isolate them from each other. You may not need to
> do that so long as you don't have other things in /mnt being used that
> may cause a pwd.
>
> if you run ls -l /proc/*/cwd | more it will show you everything
> running's cwd. I see /var/spool/at (atd process) with that as a home
> dir, so atd doing a pwd would cause a spinup.
>
> I don't actively use atd for anything and strace does not show atd
> doing anything on my machine. If you use atd then it may be what is
> doing it. nfs's statd also its cwd under var and is used on nfs
> servers.
>
> On Wed, Feb 12, 2020 at 1:11 PM Dave Ulrick <d-ulr...@comcast.net> wrote:
>
> >
> >
> > On 2/12/20 7:53 AM, Dave Ulrick wrote:
> >
> > > Interesting thought. I can envision how a lookup for /var/xyz could
> > > cause everything under /var to be looked up, and I can see how
> > > /var/cache or /var/run would be frequently read. I'll try mounting a
> > > green USB drive's file system at a third-level directory (e.g.,
> > > /var/backups/0) or under a less popular directory (e.g., /mnt/backups)
> > > and see if that behaves any differently.
> >
> >
> >
> > I ran 'strace' on 'ls' but nothing interesting showed up. Then, I ran
> > 'strace' on 'bash'. I ran 'ls' from 'bash' and then exited. The strace
> > log shows two connect()s to a socket file under /var/run:
> >
> >
> >
> > socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> > connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) =
> > -1 ENOEN
> > T (No such file or directory)
> > close(3)
> >
> >
> >
> > /var/run/nscd/socket appears to be related to the 'nscd' DNS cache which
> > I am not running on my PCs.
> >
> >
> >
> > So, it looks likely that reading /var/run caused the contents of /var to
> > be read. This would have triggered a wakeup of the device hosting
> > /var/backups which would be a cause of its hard drive spinning up.
> >
> >
> >
> > In addition to one PC that mounted a green USB drive under /var I had
> > several other PCs that mounted a NAS under /var. That NAS is intended to
> > store backup files so its hard drive is configured to spin down after 10
> > idle minutes.
> >
> >
> >
> > In view of these findings, I've reconfigured my PCs to mount the backups
> > directory under /mnt instead of /var. So far since doing so I've not
> > noticed any spin-up delays related to a USB hard drive or the backup NAS.
> >
> >
> >
> > Thanks, Tim!
> >
> >
> >
> > Dave
> >
> >
> >
> > _______________________________________________
> > users mailing list -- users@lists.fedoraproject.org
> > To unsubscribe send an email to users-le...@lists.fedoraproject.org
> > 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@lists.fedoraproject.o
> > rg
> _______________________________________________
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
I am a little confused by getcwd(), on linux it is supposed to be a system call
.. I expect to find a
manual page for it in section 2 (man 2 getcwd)
instead it gives me the library function manual page from section 3 (man 3
getcwd)
I would fully expect a libc version of getcwd to make many system calls to
traverse the current
path but here getcwd() is a system call with all work done internally in the
kernel, so I wouldnt
expect anything to probe the path elements.
When I knock up a simple program to do a getcwd() and strace it I find that
getcwd (on FC31
anyway) IS a system call.
Why does "man getcwd" give me a page from section 3?
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
