Ssh spins up all file server hard drives. Any ideas on why? (hdparm related)
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Ssh spins up all file server hard drives. Any ideas on why? (hdparm related)
I have a home file server (i.e., NAS) running Ubuntu 12.04 minimal. The system disk and home directories are on a USB flash drive and there are 6 spinning hard drives containing my data (They are separate disks, not configured for RAID). They are connected to SATA ports on my motherboard. Most of them get little regular use, so I keep the rotating disks spun down (i.e., I use hdparm to spin them down after an hour of inactivity). Whenever I try and read from one of them (generally over samba) it spins up without waking the other 5. That's just what I want.
Everything works great except that if I wait a few days and then ssh into the server, for some reason all 6 rotating disks spin up (the login takes a long time while it waits for them) despite the fact that I have not tried to access any of them. If I then spin them down (or let them spin down using the timeout) and then ssh in again, they do not spin up unless I try and access them, which is the behavior I want.
A few more specifics of my system, in case they matter:
* I do run apache, with all the apache content on the USB drive (available only to the LAN). I don't think it should be touching my data drives.
* I login to ssh using asymmetric key authentication. The .ssh directory is in my home directory, which is on the USB flash drive.
* I have a .hushlogin file in my home directory, so there's no message of the day or anything. Actually I'm not sure all of what .hushlogin does.
* My shell is bash.
* None of the data drives or their subdirectories is in my path.
* I can only test this once a day at most (probably less frequently than that) because if it hasn't been too long, there is no problem on login (i.e., none of the drives feel compelled to spin up unless they are actually desired.
* I do have to log in to this server relatively frequently as this is how I connect to my home box from outside the network (that is, I connect to my file server, which is always on, and run a script on it that wakes my regular box, then ssh to the regular box).
Do you have any ideas on what is causing the wakeup signal to be sent to all those drives? Or if there's a log file that is likely to have information on what happened, that would be a great start.
Interesting. I wonder if spin-ups are controlled by the kernel or by user land? The "vm.block_dump" sysctl dumps inode nfo to syslog, can't remember if it logs device names as well though, and logging syscalls could be done using the audit service. Logging to disk needs syscalls too so at first best limit any rule to stat.* and read I think.
Sorry, some of that went above my head. Tell me if I'm on the right track:
I tailed /var/log/syslog and the last entry was a couple of weeks ago although I experienced the spinup issue just now, so I don't think it's being logged there. I assume that's what you were referring to.
When one connects by ssh, what things happen? It should just be .profile, .bashrc, /etc/bash.bashrc, right?
Is there a sleep state (computerwide) that might be happening and when it wakes, it also spins up the drives? Shot in the dark, here.
I need to test whether it also happens when it log in with a password. I'll test tomorrow.
I tailed /var/log/syslog and the last entry was a couple of weeks ago although I experienced the spinup issue just now, so I don't think it's being logged there. I assume that's what you were referring to.
If your last syslog entry was from weeks ago then you've edited your system logging to be even less than minimalistic I suppose? And no unless you explicitly 'sysctl -w vm.block_dump=1' it won't show anything as it's more of a debugging tool.
Quote:
Originally Posted by farnsy
When one connects by ssh, what things happen? It should just be .profile, .bashrc, /etc/bash.bashrc, right?
In short I'd say: connection stream arrives, kernel hands request to sshd, which does handshaking, accepts connection and forks [priv] child, which forks ssh login under the users UID, which forks the users shell.
I've been working on a new hypothesis and so far it seems to have worked (I'd like to check if it's even reasonable, though, in case it has been a coincidence):
The system drive is a USB flash drive, so I was thinking maybe the issue had to do with a USB suspend function (the computer itself never goes to sleep that I've seen). I was thinking maybe when I try and ssh in and the system drive (and my home directory) is not available a more general wakeup command got issued that affected the spinning drives.
To check this I pass usbcore.autosuspend=-1 to the kernel at boot. I've only been able to check the computer a few times since then, but each time the computer was working correctly and no time did it make me wait nor spin up all the SATA drives.
Do you think this is a coincidence, or can you imagine my hypothesis being correct? Somehow I thought USB suspend functions worked at a much higher frequency (like, a few seconds after last use) but until recently I had never even heard of USB suspend, so I'm by no means an expert on the subject.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.