Re: Long wait for start job

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2021-06-14 at 18:02 +0800, Ed Greshko wrote:
> On 14/06/2021 17:52, Patrick O'Callaghan wrote:
> > On Mon, 2021-06-14 at 03:42 +0800, Ed Greshko wrote:
> > > On 13/06/2021 23:57, Patrick O'Callaghan wrote:
> > > > I did the same and it has made a big difference, i.e. I no
> > > > longer
> > > > have
> > > > the very long delay waiting for usb-settle.
> > > > 
> > > > I still don't know why my external dock is being mounted at
> > > > boot,
> > > > but I
> > > > can live with it for now.
> > > I've not thought about these issues you're having in quite some
> > > time.  But, while servicing a cat
> > > at 3AM I started to wonder.
> > > 
> > > If you were to disable the dock-watch.service does the boot
> > > process
> > > complete quickly?
> > > 
> > I tried 'systemctl disable dock-watch' but for some reason it's
> > being
> > re-enabled on boot, so that has no effect.
> 
> Are you saying that after doing a "systemctl disable" it shows up as
> "enabled" after
> a reboot?
> 
> I wonder if getting started is due to Wants=dock-watch.service in
> raid.mount.
> 
> 
> > I physically disconnected the dock and it does make a big
> > difference,
> > so there's no doubt where the problem lies.
> > 
> > > If it does, might there be a way to start the service after the
> > > boot
> > > process is completed?
> > > 
> > If I can manage to actually disable dock-watch from starting
> > automatically then presumably I could run it from crontab using an
> > '@reboot' line.
> 
> For a "test" you may want to try masking the service.

I commented out the Wants line in raid.mount and removed the dock-
watch.service file (masking it gave an error). This effectively removed
the boot delay.

Now I'm considering whether to junk the whole dock-watch idea and use
Chris's suggestion of a udev rule to just set the drives' standby
values directly.

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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux