|
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@xxxxxxxxxxx> 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@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@lists.fedoraproject.o > > rg > _______________________________________________ > 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
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@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
