On Sat, 2021-03-27 at 11:29 -0500, Roger Heflin wrote: > > > You probably should send the power down and wait a few seconds > > > before > > > starting the loop. It would seem to be pretty likely that if > > > in > > > the > > > middle of the spin-down *ANY* command that is received causes it > > > to > > > power the disk fully back up and aborts the spin-down. But once > > > the > > > disk is completely spun-down that specific command does not spin > > > the > > > disk back up. In the middle of the spin-down it would appear > > > that > > > the disk is not yet in the certain commands do not cause a spin- > > > up > > > state. This would assume the disk has 2 operational states. > > > When > > > in > > > the spun-up state any command causes a spin-up, once in the spun- > > > down > > > state certain commands don't cause a spin-up. And until the > > > spin-down is completed it would appear it is still in the first > > > state. > > > > Although that seems very reasonable, it doesn't explain why the > > *exact > > same script* works when used from the command line, and doesn't > > work > > when called from the systemd unit. All the looping, delaying, > > checking > > etc. is within the script itself. > > > > poc > > So on the command line the script never exits? And neither does it > exit in systemd? So in both cases it is always running. Not at all. The script was exiting because it thought it had successfully spun down the drive. The problem was that the drive would immediately spin up again (after the script had exited). In the most recent version, with extra looping and checks, it now seems to be working correctly in both cases (systemd and command line). > In the command line case you leave it running all of the time so in > either case it should be noticing the umount at the same timing? It's not running all the time. It starts when automount triggers it, waits for an inotifywait unmount event, spins down, then exits. > IE you don't run it when you detect the umount it is running and > always watching? What is it using to detect the umount? Is the > command like script already fully running when the automount happens > or do you manually start it and the disk was already umounted? > > I have had issues before with the notifies triggering a create event > and running the associated script so fast that the triggered script > copied an empty file. In my case it was triggering on a file create > and the script was starting and copying the file before the file was > even written to. And the code writing to the file should have been a > quick open/write/close that had very little delay in it but the > notify > on the file create + calling a script was beating the file being > finished. I had to put a short sleep in it to give it a bit to > complete the file write/close. The script has sleeps at various points to prevent this kind of race. That isn't the issue. The script logs what it's doing and it works correctly. The unexplained spin-up is being caused by something else. As mentioned previously, I've now added extra checks to the script to detect if such a spin-up occurs and repeat the spin-down command. So far it seems to need this three times before it settles. For now I'm going to leave it at that for a day or two to see if it keeps working. I'll come back to it if there's anything new to report. poc _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
