28.04.2017 12:05, Julian Andres Klode пишет:
> On Fri, Apr 28, 2017 at 08:46:45AM +0200, Michal Sekletar wrote:
>> On Thu, Apr 27, 2017 at 11:30 PM, Julian Andres Klode
>> wrote:
>>
>>> Now, we seem to be missing one bit: If daily-upgrade is already
>>> running, and daily is about to start, daily
On Thu, Apr 27, 2017 at 9:50 PM, Michael Chapman
wrote:
> On Fri, 28 Apr 2017, Felipe Sateler wrote:
>
>> On Thu, 27 Apr 2017 15:53:51 +1000, Michael Chapman wrote:
>>
>> Hello all,
>>>
>>> At present, when systemd-fstab-generator creates an automount unit for
>>> an fstab entry, it applies the d
On Fri, Apr 28, 2017 at 11:05 AM, Julian Andres Klode wrote:
> From my testing, if B has After=A, and A is already started, the
> startup of B is delayed until A has completed - do you mean that
> with run queue, or is that merely by accident somehow?
Like I said, we can't do anything about job t
On Fri, Apr 28, 2017 at 08:46:45AM +0200, Michal Sekletar wrote:
> On Thu, Apr 27, 2017 at 11:30 PM, Julian Andres Klode wrote:
>
> > Now, we seem to be missing one bit: If daily-upgrade is already
> > running, and daily is about to start, daily should wait for
> > daily-upgrade to finish. I had
Hi,
On big setups (read: a lot of multipathed disks), probing and
assembling storage may take significant amount of time. However, by
default systemd waits only 90s (DefaultTimeoutStartSec) for
"top-level" device unit to show up, i.e. one that is referenced in
/etc/fstab.
One possible solution is
