On Sat, Mar 27, 2021 at 9:35 AM Patrick O'Callaghan pocallaghan@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.