Wireshark won't help as it won't tell you what process is doing. And decoding the commands will be very difficult. 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. On Sat, Mar 27, 2021 at 7:18 AM Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote: > > On Sat, 2021-03-27 at 09:50 +0800, Ed Greshko wrote: > > On 27/03/2021 07:20, Patrick O'Callaghan wrote: > > > This never happens if I run the script directly from the command > > > line > > > (i.e. the drives power down and stay down). > > > > > > Clearly the docking unit isn't just doing this flakily on its own. > > > Something is making it happen, and I've no idea how to discover > > > what it > > > is except that it seems to be correlated with systemd in some way. > > > > Just "thinking out loud" here. > > > > When you run the script from the command line it is after you've > > determined the unmount > > has happened. How much time do you think elapsed between the actual > > unmount and > > running of the script? Do you have a delay between the time > > inotifywait detects unmount > > and powering down the drives? If so, does it help if you extend the > > delay? > > The power-down script loops as long as it detects that the drives are > spun up (using hdparm -C), since they take few seconds to actually spin > down. I can physically see them being spun down, then a couple of > seconds later they spin up again, which can only be because something > is accessing them. If I then invoke the same power-down script > manually, they power down and stay down. > > I've now modified the script to run an outer loop three times over the > power-down-and-check sequence, which so far seems to do the trick, but > it's a real kludge. > > > I have never used it for this, but wireshark does have the ability to > > monitor USB. Don't > > know if that will reveal anything or be of any help. > > Only as a last resort. I don't fancy having to learn USB command > sequences. > > 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 _______________________________________________ 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
