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(a)gmail.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> 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.org
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure