On Fri, Apr 28, 2017 at 11:05 AM, Julian Andres Klode <j...@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. >> 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
