On Thu, 2021-03-18 at 06:50 +0800, Ed Greshko wrote: > On 17/03/2021 23:10, Ed Greshko wrote: > > On 17/03/2021 22:22, Patrick O'Callaghan wrote: > > > On Mon, 2021-03-15 at 10:40 +0800, Ed Greshko wrote: > > > > On 15/03/2021 07:37, Patrick O'Callaghan wrote: > > > > > The only remaining problem (touch wood) is to get the power- > > > > > down > > > > > script > > > > > to run after a timeout. I'll consider writing a special > > > > > script to > > > > > monitor the mount status independently of systemd. > > > > You can consider using the timer/service pair of systemd. > > > > > > > > Add another Wants to raid.mount of say "raid.timer". Then.... > > > > > > > > 1. Upon mount, raid.timer is started. > > > > 2. After defined time, raid.timer calls "raid.service". > > > > 3. raid.service checks mount status. > > > > 4. If still mounted then exit. Meaning goes back to waiting > > > > and #2. > > > > 5. If now unmounted, power off the hub and stop raid.timer. > > > > So, > > > > basically, raid.service no long runs > > > > and you're back to condition #1 which starts the timer > > > > again on > > > > the next mount. > > > OK, I'm attempting to do that, but it's not quite there. The main > > > problem seems to be getting the timer to fire more than once (did > > > I > > > mention how obscure the systemd docs are?). As it stands, the > > > raid.service unit checks the mounted status immediately rather > > > than > > > waiting, and of course it always succeeds, but then just > > > finishes. > > > > > > I attach the current systemd files. The 'dock' script is now > > > considerably simplified (it turns out that all the bus scanning > > > is > > > unnecessary as I can just use ' hdparm -y' to spin down, and > > > spinning > > > up is automatic). The 'cdown' argument powers down the dock > > > conditionally, i.e. if it's not mounted. > > > > > > > I'll have a look at this on my tomorrow... > > Before I drifted off I decided to adhere to the KISS principle. So, > I decided against the timer/service > pair in favor of a simpler approach. > > See the attached examples. > > This results in.... > > [root@f33k auto]# pwd > /var/tmp/auto > > [root@f33k auto]# ll > total 0 > > [root@f33k auto]# ls /aux > backups linux-releases qemu-images > > [root@f33k auto]# ll > total 0 > -rw-r--r--. 1 root root 0 Mar 18 06:46 dock-up > > And one minute later > > [root@f33k auto]# ll > total 0 > -rw-r--r--. 1 root root 0 Mar 18 06:47 dock-down > -rw-r--r--. 1 root root 0 Mar 18 06:46 dock-up Right. I had to stare at that for a while but I get it. The dock-down script is doing the timeout, not systemd itself. I'll try that and see what happens. > I don't know if the power up/down of the dock takes time...so I may > be necessary to adjust sleep times. Sure. I'll report back once I've tested for a few days. 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
