On 12Feb2020 19:09, Roger Heflin rogerheflin@gmail.com 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 /.
getcwd() is a system call on Linux since 2.1.92. It doesn't need to perform the expensive ".. then stat everything for a match" loop.
[... snip arranging mounts to be in more out-of-the-way places ...]
On Wed, Feb 12, 2020 at 1:11 PM Dave Ulrick d-ulrick@comcast.net wrote:
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.
Aye.
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.
This would surprise me; accessing a direct name doesn't require stating everything adjacent.
You can test this:
- wait for the drive to spin down - type ">>var/run/nscd/socket" and preess <enter> (do NOT filecomplete that path, your shell will do unwanted filesystem access) - see if/when the drive spins up
Cheers, Cameron Simpson cs@cskk.id.au