Description of problem: We have service A and service B. Service B requires service A, but it can require service A from different host (depends on configuration). So we've added After=A in service B and also Before=B in service A, but it did not help. Expected result was B is started and if A is configured to stat too, it should be started before B. Version-Release number of selected component (if applicable): systemd-26-1.fc15.x86_64 How reproducible: always Steps to Reproduce: 1.testA.service with After=testB.service, testB.service with Before=testA.service 2.systemctl start testA.service testB.service 3. Actual results: testA.service and testB.service started in A, B order despite configuration requires opposite order Expected results: testA.service and testB.service started in B, A order as requested by configuration
"systemctl start testA.service testB.service" starts the services one by one in the order they are given on the command line. It does not start them in a single transaction. It probably should. Note that the After and Before dependencies will be enforced in the usual scenario of starting the services during the boot transaction, or if you create a target (let's call it testAB.target) pulling the two services using Wants and then use systemctl start testAB.target Also note that it is sufficient to express the ordering dependency in one of the units. It is redundant to give both Before and After telling the same information.
Yes, we should make it possible to start multiple services on one command line in a single transaction.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Given that we will be only back porting important fixes for F15 at this point in time I'm moving this RFE against Rawhide so it does not get forgotten or lost in the EOL process.
I already have a patch witch enables me to run an systemctl action on multiple units in a single transaction. From the perspective of job dependencies, my implementation does following (assume that command systemctl --one-transaction start a.service b.service c.service has been issued, note that boxes represent particular jobs and arrows denotes dependencies between jobs) : +-----------+ +-------------------+ +------------+ | c.service |<---------| a.service(anchor) |------->| b.service | +-----------+ +-------------------+ +------------+ | | | | | | V V V +--------------+ +--------------+ +---------------+ | c.service | | a.service | | b.service | | dependencies | | dependencies | | dependencies | +--------------+ +--------------+ +---------------+ Using this approach I was able to achieve desired behavior as stated in the bug description. However, there is one issue I struggle with. What should be returned back as a result of a dbus method call. Now we return single dbus path associated with the anchor job. This is not sufficient any more, we have to return more dbus paths for respective jobs, which were explicitly requested by user. Does it imply that we should have more anchor jobs? If job is not an the anchor job it might get dropped from transaction. There might be more issue, like conflicting jobs etc... . I'm asking in advance, because this kinda affects overall design of transactional model in systemd and I don't want to waste time implementing something which is likely to be rejected later on. Hopefully I made myself clear. Follow-up discussion is very welcome, however if you guys decide that we can speak about this at the hack-fest I don't mind since I think this is not the pressing issue.
ping?