Bug 704214 - RFE: make it possible to invoke to services from the systemctl command line in a single transaction
Summary: RFE: make it possible to invoke to services from the systemctl command line i...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Sekletar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: systemd-RFE
TreeView+ depends on / blocked
 
Reported: 2011-05-12 13:12 UTC by Michal Hlavinka
Modified: 2022-08-12 12:19 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-08-12 12:19:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github systemd systemd issues 8102 0 None open pid1: accept single transaction to operate multiple units 2022-08-12 12:19:56 UTC

Description Michal Hlavinka 2011-05-12 13:12:46 UTC
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 15:01:26 UTC
"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 13:21:16 UTC
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 16:27:16 UTC
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 11:42:53 UTC
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 18:25:14 UTC
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 10:08:07 UTC
ping?


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