On Sat, 2021-03-27 at 07:36 +0800, Ed Greshko wrote:
> On 27/03/2021 07:24, Patrick O'Callaghan wrote:
> > Just a quick comment: I think the x-systemd.mount-timeout entry in
> > aux.mount should be x-systemd.idle-timeout, at least according to
> > the
> > systemd.mount man page.
>
> Actually, it s
The duration of this tread has me laughing at the systemd
"Biggest Myths" web page again:
http://0pointer.de/blog/projects/the-biggest-myths.html
Especially the claims that it is easily scriptable :-).
___
users mailing list -- users@lists.fedoraproject
On 27/03/2021 07:24, Patrick O'Callaghan wrote:
Just a quick comment: I think the x-systemd.mount-timeout entry in
aux.mount should be x-systemd.idle-timeout, at least according to the
systemd.mount man page.
Actually, it should not be there at all. I had copied it the fstab and it was
actual
On Wed, 2021-03-24 at 06:02 +0800, Ed Greshko wrote:
> On 23/03/2021 18:57, Patrick O'Callaghan wrote:
> > Sure, I'd like to see it. I've been testing various mods to the
> > whole
> > thing because I couldn't get it to work reliably, i.e. the loop
> > waiting
> > for the unmount would work when ru
On Tue, 2021-03-23 at 22:40 +, Patrick O'Callaghan wrote:
> On Wed, 2021-03-24 at 06:02 +0800, Ed Greshko wrote:
> > On 23/03/2021 18:57, Patrick O'Callaghan wrote:
> > > Sure, I'd like to see it. I've been testing various mods to the
> > > whole
> > > thing because I couldn't get it to work re
On Wed, 2021-03-24 at 06:02 +0800, Ed Greshko wrote:
> On 23/03/2021 18:57, Patrick O'Callaghan wrote:
> > Sure, I'd like to see it. I've been testing various mods to the
> > whole
> > thing because I couldn't get it to work reliably, i.e. the loop
> > waiting
> > for the unmount would work when ru
On 23/03/2021 18:57, Patrick O'Callaghan wrote:
Sure, I'd like to see it. I've been testing various mods to the whole
thing because I couldn't get it to work reliably, i.e. the loop waiting
for the unmount would work when run directly from the shell, but not
when run from a systemd service. I thi
On Tue, 2021-03-23 at 14:08 +0800, Ed Greshko wrote:
> On 18/03/2021 23:01, Patrick O'Callaghan wrote:
> > Sure.
> >
> > I'll report back once I've tested for a few days.
>
> Today was a slow day. So I implemented the "dock-down" with a timer
> instead of
> a while loop. Let me know if you're
On 18/03/2021 23:01, Patrick O'Callaghan wrote:
Sure.
I'll report back once I've tested for a few days.
Today was a slow day. So I implemented the "dock-down" with a timer instead of
a while loop. Let me know if you're interested in it.
--
Remind me to ignore comments which aren't germane
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 (
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 consi
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
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
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.
On Mon, 2021-03-15 at 06:52 +0800, Ed Greshko wrote:
> On 15/03/2021 06:10, Patrick O'Callaghan wrote:
> > On Mon, 2021-03-15 at 05:09 +0800, Ed Greshko wrote:
> > > On 15/03/2021 00:31, Patrick O'Callaghan wrote:
> > > > I rebooted and got:
> > > >
> > > > # findmnt /raid
> > > > # ls /raid
> > >
On 15/03/2021 06:10, Patrick O'Callaghan wrote:
On Mon, 2021-03-15 at 05:09 +0800, Ed Greshko wrote:
On 15/03/2021 00:31, Patrick O'Callaghan wrote:
I rebooted and got:
# findmnt /raid
# ls /raid
# findmnt /raid
#
IOW nothing happens.
systemctl status raid.mount
systemctl status raid.automou
On Mon, 2021-03-15 at 05:09 +0800, Ed Greshko wrote:
> On 15/03/2021 00:31, Patrick O'Callaghan wrote:
> > I rebooted and got:
> >
> > # findmnt /raid
> > # ls /raid
> > # findmnt /raid
> > #
> >
> > IOW nothing happens.
>
> systemctl status raid.mount
> systemctl status raid.automount
> systemc
On 15/03/2021 00:31, Patrick O'Callaghan wrote:
I rebooted and got:
# findmnt /raid
# ls /raid
# findmnt /raid
#
IOW nothing happens.
systemctl status raid.mount
systemctl status raid.automount
systemctl status dock.service
and finally
mount /raid
--
People who believe they don't make mist
On Sun, 2021-03-14 at 07:37 +0800, Ed Greshko wrote:
> > > Your dock.service, if run, would power-up and then immediately
> > > power-down the dock.
> > Indeed. Does that mean I need separate dock-up and dock-down
> > services?
>
> I suppose. But, I can't say that there is a way to start a servic
On Sun, 2021-03-14 at 18:11 +1030, Tim via users wrote:
> On Fri, 2021-03-12 at 11:18 +, Patrick O'Callaghan wrote:
> > 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 t
On Fri, 2021-03-12 at 11:18 +, Patrick O'Callaghan wrote:
> 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
On 14/03/2021 07:14, Patrick O'Callaghan wrote:
On Sun, 2021-03-14 at 06:38 +0800, Ed Greshko wrote:
[root@f33k ~]# systemctl status dock.service
● dock.service - Power the dock up or down
Loaded: loaded (/etc/systemd/system/dock.service; static)
Active: inactive (dead)
[root@f33k
On Sun, 2021-03-14 at 06:38 +0800, Ed Greshko wrote:
> [root@f33k ~]# systemctl status dock.service
> ● dock.service - Power the dock up or down
> Loaded: loaded (/etc/systemd/system/dock.service; static)
> Active: inactive (dead)
>
> [root@f33k ~]# systemctl start dock.service
>
> [r
On 14/03/2021 03:02, Patrick O'Callaghan wrote:
I assume there must be a basic error here, but I'm at a loss.
I like to crawl before I walk and walk before I run.
Even then, I see a pitfall in your plan. So, I created a test
/etc/systemd/system/dock.service.
[root@f33k system]# cat dock.ser
On Sat, 2021-03-13 at 08:49 -0500, Jonathan Billings wrote:
> On Mar 12, 2021, at 19:05, Ed Greshko wrote:
> >
> > I don't think systemd was meant to solve these sorts of issues
>
> Honestly, systemd is more equipped to handle this kind of issue than any init
> system before it. Being able to
On Sat, 2021-03-13 at 08:49 -0500, Jonathan Billings wrote:
> On Mar 12, 2021, at 19:05, Ed Greshko wrote:
> >
> > I don't think systemd was meant to solve these sorts of issues
>
> Honestly, systemd is more equipped to handle this kind of issue than any init
> system before it. Being able to
On Mar 12, 2021, at 19:05, Ed Greshko wrote:
>
> I don't think systemd was meant to solve these sorts of issues
Honestly, systemd is more equipped to handle this kind of issue than any init
system before it. Being able to attach dependencies in a .mount unit to a
.service unit is something th
On Sat, 2021-03-13 at 08:04 +0800, Ed Greshko wrote:
> > Of course it's possible that sending some command to the dock would
> > power down the drives, but the thing has no useful documentation.
> > It
> > just comes with (of course) a Windows driver.
>
> OK My understanding is that the HW yo
On 13/03/2021 01:29, Patrick O'Callaghan wrote:
On Fri, 2021-03-12 at 22:39 +0800, Ed Greshko wrote:
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 state
On Fri, 2021-03-12 at 22:39 +0800, Ed Greshko wrote:
> > > 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
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
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
> > >
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 someho
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
> neede
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 moun
On Thu, Mar 11, 2021 at 01:13:08PM +, Patrick O'Callaghan wrote:
>
> Yes, I had noticed that. What isn't clear to me is how this would work
> on system reboot. I need to be able to power down the drive not just
> after it's unmounted, but when the system is rebooted and the drive
> hasn't been
On Thu, 2021-03-11 at 13:13 +, Patrick O'Callaghan wrote:
> On Thu, 2021-03-11 at 07:47 -0500, Jonathan Billings wrote:
> > On Mar 10, 2021, at 20:18, Ed Greshko wrote:
> > >
> > > The answer may be "none of the above".
> > >
> > > Diving into systemd documentation it seems that the sections
On Thu, 2021-03-11 at 07:47 -0500, Jonathan Billings wrote:
> On Mar 10, 2021, at 20:18, Ed Greshko wrote:
> >
> > The answer may be "none of the above".
> >
> > Diving into systemd documentation it seems that the sections included in
> > the mount and automount unit files
> > don't define thos
On Mar 10, 2021, at 20:18, Ed Greshko wrote:
>
> The answer may be "none of the above".
>
> Diving into systemd documentation it seems that the sections included in the
> mount and automount unit files
> don't define those lines. :-(
There isn’t anything about exec lines in a .mount unit, wh
On Thu, 2021-03-11 at 15:38 +0800, Ed Greshko wrote:
> On 11/03/2021 09:17, Ed Greshko wrote:
> > On 11/03/2021 01:40, Patrick O'Callaghan wrote:
> > > I now have to work out where to put the ExecStart/Stop lines.
> >
> > The answer may be "none of the above".
> >
> > Diving into systemd document
On 11/03/2021 09:17, Ed Greshko wrote:
On 11/03/2021 01:40, Patrick O'Callaghan wrote:
I now have to work out where to put the ExecStart/Stop lines.
The answer may be "none of the above".
Diving into systemd documentation it seems that the sections included in the
mount and automount unit fi
On 11/03/2021 01:40, Patrick O'Callaghan wrote:
I now have to work out where to put the ExecStart/Stop lines.
The answer may be "none of the above".
Diving into systemd documentation it seems that the sections included in the
mount and automount unit files
don't define those lines. :-(
--
P
On Wed, 2021-03-10 at 23:04 +0800, Ed Greshko wrote:
> On 10/03/2021 22:35, Ed Greshko wrote:
> > Also, due to the late hour, I seem to recall seeing something about working
> > with automounts and external devices
> > and conflicts arising due to the interference of udev. But I may be mixing
>
On Wed, 2021-03-10 at 22:35 +0800, Ed Greshko wrote:
> On 10/03/2021 20:57, Patrick O'Callaghan wrote:
> >
> > [Sorry for the long delay, but other stuff intervened.]
> >
> > I've come back to this now and started experimenting incrementally. As
> > a first step, I just want to automount/unmount,
On 10/03/2021 22:35, Ed Greshko wrote:
Also, due to the late hour, I seem to recall seeing something about working
with automounts and external devices
and conflicts arising due to the interference of udev. But I may be mixing
things. So, I'd first see if making the
above changes has any effe
On 10/03/2021 20:57, Patrick O'Callaghan wrote:
[Sorry for the long delay, but other stuff intervened.]
I've come back to this now and started experimenting incrementally. As
a first step, I just want to automount/unmount, ignoring the power-
on/off part for now, i.e. the device is already powe
On Mon, 2021-03-01 at 03:27 +0800, Ed Greshko wrote:
> On 01/03/2021 01:12, Patrick O'Callaghan wrote:
> > Is there a way to invoke scripts before auto-mounting and after auto-
> > unmounting? I want to be able to power an external drive up and down as
> > needed.
> >
>
> Well, using systemd unit
On Sun, 2021-02-28 at 18:03 -0700, Chris Murphy wrote:
> On Sun, Feb 28, 2021 at 10:13 AM Patrick O'Callaghan
> wrote:
> >
> > Is there a way to invoke scripts before auto-mounting and after auto-
> > unmounting? I want to be able to power an external drive up and down as
> > needed.
>
> If you
On Sun, Feb 28, 2021 at 10:13 AM Patrick O'Callaghan
wrote:
>
> Is there a way to invoke scripts before auto-mounting and after auto-
> unmounting? I want to be able to power an external drive up and down as
> needed.
If you don't need much sophistication, you can add to fstab with options:
noaut
On Sun, 2021-02-28 at 16:18 -0500, Jonathan Billings wrote:
> On Feb 28, 2021, at 12:13, Patrick O'Callaghan wrote:
> >
> > Is there a way to invoke scripts before auto-mounting and after auto-
> > unmounting? I want to be able to power an external drive up and down as
> > needed.
>
> Your .mou
On Mon, 2021-03-01 at 03:27 +0800, Ed Greshko wrote:
> I would think using "ExecStartPre=" and "ExecStartPost=" would get you want
> you desire.
OK, that looks promising. I have some reading to do (though I've always
found the systemd docs fairly impenetrable).
poc
__
On Feb 28, 2021, at 12:13, Patrick O'Callaghan wrote:
>
> Is there a way to invoke scripts before auto-mounting and after auto-
> unmounting? I want to be able to power an external drive up and down as
> needed.
Your .mount unit would need a Before= and After= Section. Refer to a systemd
.ser
On 01/03/2021 03:27, Ed Greshko wrote:
I would think using "ExecStartPre=" and "ExecStartPost=" would get you want you desire.
Oh, there is also "ExecStop=" and "ExecStart=".
So, more "research" would be needed. But not at 03:40. :-)
--
People who believe they don't make mistakes have alread
On 01/03/2021 01:12, Patrick O'Callaghan wrote:
Is there a way to invoke scripts before auto-mounting and after auto-
unmounting? I want to be able to power an external drive up and down as
needed.
Well, using systemd units that should be possible. I use systemd to automount
nfs.
For one in
54 matches
Mail list logo
