This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 704214 - RFE: make it possible to invoke to services from the systemctl command line in a single transaction
RFE: make it possible to invoke to services from the systemctl command line i...
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-05-12 09:12 EDT by Michal Hlavinka
Modified: 2014-03-16 23:38 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michal Hlavinka 2011-05-12 09:12:46 EDT
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
Comment 1 Michal Schmidt 2011-05-12 11:01:26 EDT
"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.
Comment 2 Lennart Poettering 2011-05-15 09:21:16 EDT
Yes, we should make it possible to start multiple services on one command line in a single transaction.
Comment 3 Fedora Admin XMLRPC Client 2011-10-20 12:27:16 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Jóhann B. Guðmundsson 2012-02-20 06:42:53 EST
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.
Comment 5 Michal Sekletar 2012-12-07 13:25:14 EST
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.
Comment 6 Harald Hoyer 2013-04-10 06:08:07 EDT
ping?

Note You need to log in before you can comment on or make changes to this bug.