On 12/03/2021 20:40, Patrick O'Callaghan wrote:
On Fri, 2021-03-12 at 19:36 +0800, Ed Greshko wrote:
On 12/03/2021 19:18, Patrick O'Callaghan wrote:
On Fri, 2021-03-12 at 17:01 +0800, Ed Greshko wrote:
On 11/03/2021 21:14, Patrick O'Callaghan wrote:
Someone on the SystemD list suggested using an @reboot line in crontab
for this, as a special case.
While I didn't think of that option, I somehow got the impression that you needed/wanted to run a script of
some sort each time the share was mounted and unmounted.
I do. The @reboot suggestion is only a partial solution. Given that the
drive is automatically powered up on reboot (there seems to be no way
to prevent this as it's triggered by the system scanning the USB bus) I
need to be able to power it down, but currently there's no systemd
mount event to cause this to happen. No doubt there's a more elegant
way around this, but baby steps ...
Well, if it can't be done with systemd then a possible inelegant solution is to have a
"watcher" background process (or cron job that run periodically) that checks to see if
the share has gone from a mounted to unmounted state and then run the appropriate
script?
Of course. In the pre-systemd days that would have been the obvious
choice. I just thought systemd was supposed to make things more
organised, but I'm starting to wonder. I don't want to come across as a
systemd sceptic, but IMHO its highly modular structure is reflected in
the scattered nature of the documentation, which is a major impediment
to really understanding it.
To be frank, I still don't know/understand all of your requirements.
I understand the one requirement at system boot time and can see how the answer to that
is probably best handled with an @reboot cron job.
I don't know, or maybe just don't understand, what needs doing during "normal operation".
By "normal operation" I mean the system being up but the share only being accessed
periodically.
It may very well be that your use case isn't something systemd was designed to do. Or,
maybe can be done but would need multiple services defined.
I think, since you accepted the one response on the systemd list you effectively ended
the tread. If you needed more, I would have thought you'd inquire more.
Does something need running when the share goes from unmounted to mounted?
Just a timer. Once it's powered up and mounted, it should stay that way
until an idle timeout is triggered.
That statement confuses me. Isn't that what happens with automount and the TimeoutIdleSec=
parameter?
Again, I somehow got the impression that something more than simple automount was needed.
I suppose this kind of thing is one reason I'm happy I opted for a NAS. It runs a RAID
configuration and can be configured to power down disks when idle. :-) :-)
The disks I'm using were actually cannibalised from a NAS that died
(after about 10 years use). I stuck them in a dock and aside from this
issue they work well. The dock itself does power down after 30 minutes
disconnection, but of course while it's mounted that won't happen. I
need a script to unmount and then force the disconnection. The script
itself works, I just want it to happen automatically.
Well, I suppose I understand (sort of) my confusion. I don't know what "disconnection" means.
And, I don't know why a script is needed to unmount if that is handled by automount and its timeout.
Not that it matters, but if my NAS died I'd just go out and replace it. :-)
Also, FWIW, my nfs automounts get mounted a boot time too. The addition of the noauto option
has no effect.
--
People who believe they don't make mistakes have already made one.
_______________________________________________
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
