On Sat, Mar 27, 2021 at 9:35 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Sat, 2021-03-27 at 07:59 -0500, Roger Heflin wrote:
> Wireshark won't help as it won't tell you what process is doing. And
> decoding the commands will be very difficult.
Yes, that's what I thought.
> 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.
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?
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.