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-ulrick@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-leave@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-leave@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?