Re: [systemd-devel] Ordering (apt) timer services to not run at the same time
On 28 April 2017 at 13:01, Michal Sekletar <msekleta@redhat.com> wrote:
> On Fri, Apr 28, 2017 at 11:05 AM, Julian Andres Klode <jak@debian.org> 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 that is already dispatched.
>
> Consider, following simple units:
>
> # /etc/systemd/system/a.service
> [Service]
> ExecStart=/bin/sleep 60
>
> # /etc/systemd/system/b.service
> [Unit]
> After=a.service
>
> [Service]
> ExecStart=/bin/sleep 60
>
> When I start a.service first and then I invoke systemctl start second
> time for b.service, it will start b.service immediately. Since start
> job for a.service is already gone and a.service is already running.
>
> Now consider second scenario. b.service stays unchanged and a.service
> looks like this,
>
> # /etc/systemd/system/a.service
> [Service]
> Type=oneshot
> ExecStart=/bin/sleep 60
>
> When I start a.service in non-blocking mode (systemctl by default
> blocks until job it queued finishes) by "systemctl --no-block start
> a.service" and then I list jobs via "systemctl list-jobs" I can see
> following jobs,
>
> JOB UNIT TYPE STATE
> 441 a.service start running
>
> Then I start b.service. This time systemctl will block because start
> job for b.service is waiting on start job for a.service and that is
> still in the job queue. List of jobs then looks like this,
>
> -bash-4.4# systemctl list-jobs
> JOB UNIT TYPE STATE
> 631 a.service start running
> 667 b.service start waiting
>
> Job for b.service can't run because there is running job for a.service
> and a.service is still in activating state. That is not the case in
> first scenario, due to different type of service a.
>
> I looked over your unit files once again and I see your services are
> indeed oneshots. So this should actually work for you. I don't know
> why it doesn't.
>
B starting after A works.
What we are after is: if B is running then A should wait for B to finish first.
Aka stage1 and stage2 units, one should run after the other, and
neither should run simultaneously.
And attempts to start stage1, whilst stage2 is running should result
in waiting. It should not prematurely abort stage2 unit. Something
like a mythical ConflictsWaitFor= or some such.
>>> Indeed, seems like lockfile + condition in other unit is the simplest way out.
>>
>> How unfortunate.
>
> Scratch that, I've missed that you are using oneshot services.
>
> Michal
--
Regards,
Dimitri.
Reply to: