Need help with systemd service files

[Juerg Haefliger]

Hi,

I want to create a package for Fedora 16 but I'm struggling with the
systemd service/target files. I cannot get the various services to execute
in the right order. I have 4 services (they're actually scripts that just
execute and terminate) that need to run in the order described below. Any
of the services could fail but that shouldn't affect any of the other
services.

1) Service A after the local filesystem is mounted.
2) Service B after the network is up and service A terminated.
3) At this point I'd like to create a reference point for other services to
hook into.
4) Service C after the reference point and after syslog is up.
5) Service D after rc-local and after service C terminated.

What I have at the moment is the following:

A.service:
[unit]
Description=A
After=local-fs.target
[Service]
Type=oneshot
ExecStart=/usr/bin/A
RemainAfterExit=yes

B.service:
[unit]
Description=B
After=network.target A.service
[Service]
Type=oneshot
ExecStart=/usr/bin/B
RemainAfterExit=yes

C.target:
[unit]
Description=C
After=A.service B.service

C.service:
[unit]
Description=C
After=syslog.target C.target
[Service]
Type=oneshot
ExecStart=/usr/bin/C
RemainAfterExit=yes

D.service:
[unit]
Description=D
After=rc-local.service C.service
[Service]
Type=oneshot
ExecStart=/usr/bin/D
RemainAfterExit=yes


[    2.417488] systemd[1]: Installed new job C.service/start as 80
[    2.417494] systemd[1]: Installed new job A.service/start as 82
[    2.417504] systemd[1]: Installed new job D.service/start as 86
[    2.417533] systemd[1]: Installed new job B.service/start as 100
[   92.455037] systemd[1]: About to execute: /usr/bin/C
[   92.460087] systemd[1]: Forked /usr/bin/C as 574
[   92.460204] systemd[1]: C.service changed dead -> start
[   92.557292] systemd[1]: About to execute: /usr/bin/A
[   92.565167] systemd[1]: Forked /usr/bin/A as 578
[   92.565289] systemd[1]: A.service changed dead -> start
[   92.954627] systemd[1]: Received SIGCHLD from PID 574 (C).
[   92.954649] systemd[1]: Got SIGCHLD for process 574 (C)
[   92.954689] systemd[1]: Child 574 belongs to C.service
[   92.954696] systemd[1]: C.service: main process exited, code=exited,
status=0
[   92.964090] systemd[1]: C.service changed start -> exited
[   92.964103] systemd[1]: Job C.service/start finished, result=done
[   92.964231] systemd[1]: Got SIGCHLD for process 578 (A)
[   92.964272] systemd[1]: Child 578 belongs to A.service
[   92.964277] systemd[1]: A.service: main process exited, code=exited,
status=1
[   92.965076] systemd[1]: A.service changed start -> failed
[   92.975063] systemd[1]: Job A.service/start finished, result=failed
[   92.975085] systemd[1]: Unit A.service entered failed state.
[   92.976434] systemd[1]: About to execute: /usr/bin/D
[   92.983105] systemd[1]: Forked /usr/bin/D as 642
[   92.983177] systemd[1]: D.service changed dead -> start
[   92.983655] systemd[1]: C.service: cgroup is empty
[   92.983696] systemd[1]: A.service: cgroup is empty
[   93.012250] systemd[1]: About to execute: /usr/bin/B
[   93.020073] systemd[1]: Forked /usr/bin/B as 649
[   93.020168] systemd[1]: B.service changed dead -> start
[   93.228193] systemd[1]: Received SIGCHLD from PID 642 (D).
[   93.228217] systemd[1]: Got SIGCHLD for process 642 (D)
[   93.228259] systemd[1]: Child 642 belongs to D.service
[   93.228273] systemd[1]: D.service: main process exited, code=exited,
status=0
[   93.236088] systemd[1]: D.service changed start -> exited
[   93.236100] systemd[1]: Job D.service/start finished, result=done
[   93.236363] systemd[1]: D.service: cgroup is empty
[  117.429569] systemd[1]: Received SIGCHLD from PID 649 (B).
[  117.429614] systemd[1]: Got SIGCHLD for process 649 (B)
[  117.429683] systemd[1]: Child 649 belongs to B.service
[  117.429704] systemd[1]: B.service: main process exited, code=exited,
status=0
[  117.437134] systemd[1]: B.service changed start -> exited
[  117.437158] systemd[1]: Job B.service/start finished, result=done
[  117.437627] systemd[1]: B.service: cgroup is empty



Do I really need 'RemainAfterExit=y'? Do I need any 'Wants' or
'Requires'?

Any help is greatly appreciated.

Thanks
...Juerg

[Michal Schmidt]

Hello,

On 02/23/2012 01:34 PM, Juerg Haefliger wrote:
>  Any of the services could fail but that shouldn't affect any of
>  the other services. 
 From this you can deduce the answer to one of your questions.
You don't want to use Requires then.

>  1) Service A after the local filesystem is mounted.
>  2) Service B after the network is up and service A terminated.
>  3) At this point I'd like to create a reference point for other services
>  to hook into.
>  4) Service C after the reference point and after syslog is up.
>  5) Service D after rc-local and after service C terminated.
>
>  What I have at the moment is the following:
>
>  A.service:
>  [unit]
>  Description=A
>  After=local-fs.target 
You don't need to state this ordering dependency, because your service
will get the default dependency on basic.target which implies
local-fs.target indirectly.

>  [Service]
>  Type=oneshot
>  ExecStart=/usr/bin/A
>  RemainAfterExit=yes
>
>  B.service:
>  [unit]
>  Description=B
>  After=network.target A.service
>  [Service]
>  Type=oneshot
>  ExecStart=/usr/bin/B
>  RemainAfterExit=yes
>
>  C.target:
>  [unit]
>  Description=C
>  After=A.service B.service
>
>  C.service:
>  [unit]
>  Description=C
>  After=syslog.target C.target 
syslog.target is always available these days, because the syslog socket 
gets activated early.

>  [Service]
>  Type=oneshot
>  ExecStart=/usr/bin/C
>  RemainAfterExit=yes
>
>  D.service:
>  [unit]
>  Description=D
>  After=rc-local.service C.service
>  [Service]
>  Type=oneshot
>  ExecStart=/usr/bin/D
>  RemainAfterExit=yes 
I don't see any [Install] sections, so I assume you simply linked the 
services manually into multi-user.target.wants.
Apparently you forgot to pull in C.target as well, so you fail to get 
the ordering the target was supposed to ensure.

>  Do I really need 'RemainAfterExit=y'? 
It depends. Do you want the services to appear as "active(exited)" or 
"inactive(dead)" after they've run? Do you want "systemctl start 
A.service" to be a no-op after boot, or should it re-run the program again?

>  Do I need any 'Wants' or 'Requires'? 
You don't want Requires, as mentioned above.
Whether you want Wants... again, it depends. Does it make sense to start 
the services without trying to start the ones that you said should be 
ordered before? Do you want the admin to be able to enable/disable each 
service separately?

Michal

[Juerg Haefliger]

Hi Michal,

>  Hello,
>
>
>  On 02/23/2012 01:34 PM, Juerg Haefliger wrote:
> >
> > Any of the services could fail but that shouldn't affect any of
> > the other services.
>
>
>  From this you can deduce the answer to one of your questions.
>  You don't want to use Requires then. 
Ok.


> > 1) Service A after the local filesystem is mounted.
> > 2) Service B after the network is up and service A terminated.
> > 3) At this point I'd like to create a reference point for other services
> > to hook into.
> > 4) Service C after the reference point and after syslog is up.
> > 5) Service D after rc-local and after service C terminated.
> >
> > What I have at the moment is the following:
> >
> > A.service:
> > [unit]
> > Description=A
> > After=local-fs.target
>
>
>  You don't need to state this ordering dependency, because your service
>  will get the default dependency on basic.target which implies
>  local-fs.target indirectly. 
Ok.


> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/A
> > RemainAfterExit=yes
> >
> > B.service:
> > [unit]
> > Description=B
> > After=network.target A.service
> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/B
> > RemainAfterExit=yes
> >
> > C.target:
> > [unit]
> > Description=C
> > After=A.service B.service
> >
> > C.service:
> > [unit]
> > Description=C
> > After=syslog.target C.target
>
>  syslog.target is always available these days, because the syslog socket gets activated
> early. 
Ok.


> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/C
> > RemainAfterExit=yes
> >
> > D.service:
> > [unit]
> > Description=D
> > After=rc-local.service C.service
> > [Service]
> > Type=oneshot
> > ExecStart=/usr/bin/D
> > RemainAfterExit=yes
>
>
>  I don't see any [Install] sections, so I assume you simply linked the services
> manually into multi-user.target.wants.
>  Apparently you forgot to pull in C.target as well, so you fail to get the ordering the
> target was supposed to ensure. 
All services have an [install] section, I just dropped them for this
email. Forgot to pull in C.target where? Should D.service contain
"After=rc-local.service C.target" then?


> > Do I really need 'RemainAfterExit=y'?
>
>
>  It depends. Do you want the services to appear as "active(exited)" or
> "inactive(dead)" after they've run? Do you want "systemctl start
> A.service" to be a no-op after boot, or should it re-run the program again? 
Rerun using 'systemctl restart' would be nice. So 'RemainAfterExit=y'
needs to stay, right?


> > Do I need any 'Wants' or 'Requires'?
>
>
>  You don't want Requires, as mentioned above.
>  Whether you want Wants... again, it depends. Does it make sense to start the services
> without trying to start the ones that you said should be ordered before? 
Not sure I understand. The sequence needs to be as described above
#1-#5, e.g. D should not start until A-C are done.


>  Do you want the admin to be able to enable/disable each service
> separately? 
The A-D services don't need to be managed separately, it's either all
of them or none.


Thanks for your help
...Juerg



>  Michal

[Michal Schmidt]

On 02/23/2012 03:35 PM, Juerg Haefliger wrote:
>  All services have an [install] section, I just dropped them for this
>  email. Forgot to pull in C.target where? Should D.service contain
>  "After=rc-local.service C.target" then? 
By "pull in" I mean making it included in the transaction. Ordering 
dependencies (such as After) have no effect on that. Only requirement
dependencies can pull units into the transaction. Units that are not in 
the transaction cannot influence the ordering of the transaction.
So you need to add "Wants=C.target" somewhere.

>  Rerun using 'systemctl restart' would be nice. So
> 'RemainAfterExit=y'
>  needs to stay, right? 
The 'restart' action will work the same in both cases.
It's the 'start' action where the difference can be seen. 'start'
won't 
do anything if the service is already active.
The 'restart' action first makes the unit stop (thus making sure it is 
inactive) and then start.

> > Do you want the admin to be able to enable/disable each service
> separately?
>
>  The A-D services don't need to be managed separately, it's either all
>  of them or none. 
In that case adding Wants makes sense.

May I know what package is this exactly? It's possible we may have 
missed something important by talking in the abstract A,B,C,D terms.

Michal

[Juerg Haefliger]

2012/2/23 Michal Schmidt <mschmidt(a)redhat.com&gt;:
>  On 02/23/2012 03:35 PM, Juerg Haefliger wrote:
> >
> > All services have an [install] section, I just dropped them for this
> > email. Forgot to pull in C.target where? Should D.service contain
> > "After=rc-local.service C.target" then?
>
>
>  By "pull in" I mean making it included in the transaction. Ordering
>  dependencies (such as After) have no effect on that. Only requirement
>  dependencies can pull units into the transaction. Units that are not in the
>  transaction cannot influence the ordering of the transaction.
>  So you need to add "Wants=C.target" somewhere. 
Hmm... So I fail to see the difference between After and Wants then.
What's the difference between ordering and requirement dependencies?

I added 'Wants' to each service/target file, listing the same services
as on the 'After' lines. Seems to be working now.


> > Rerun using 'systemctl restart' would be nice. So
> 'RemainAfterExit=y'
> > needs to stay, right?
>
>
>  The 'restart' action will work the same in both cases.
>  It's the 'start' action where the difference can be seen. 'start'
> won't do
>  anything if the service is already active.
>  The 'restart' action first makes the unit stop (thus making sure it is
>  inactive) and then start.
>
>
> >> Do you want the admin to be able to enable/disable each service
> >> separately?
> >
> >
> > The A-D services don't need to be managed separately, it's either all
> > of them or none.
>
>
>  In that case adding Wants makes sense.
>
>  May I know what package is this exactly? It's possible we may have missed
>  something important by talking in the abstract A,B,C,D terms. 
Oh sure, it's not a secret. It's cloud-init and I used abstract names
for clarity. I just realized that a Fedora package exists already.
Duh! At least I learned some Fedora packaging :-)
So I installed the official Fedora version of cloud-init but the
service startup ordering is broken there too:

[root@342 ~]# dmesg | grep cloud | grep About
[   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init start-local
[   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
[   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final
[   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start


The correct order should be:
systemd[1]: About to execute: /usr/bin/cloud-init start-local
systemd[1]: About to execute: /usr/bin/cloud-init start
systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final


Thanks for your help
...Juerg


>  Michal

[Michal Schmidt]

On 02/24/2012 01:22 PM, Juerg Haefliger wrote:
>  Hmm... So I fail to see the difference between After and Wants then.
>  What's the difference between ordering and requirement dependencies? 
See this explanation of the orthogonality of ordering and requirement 
dependencies by Lennart:
http://lists.fedoraproject.org/pipermail/devel/2011-April/150620.html

Michal

[Garrett Holmstrom]

On 2012-02-24 4:22, Juerg Haefliger wrote:
>  So I installed the official Fedora version of cloud-init but the
>  service startup ordering is broken there too:
>
>  [root@342 ~]# dmesg | grep cloud | grep About
>  [   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init start-local
>  [   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
>  [   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final
>  [   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start 
This is strange.  Cloud-init is split into four services that mirror 
their upstart counterparts.  The two services that run 
/usr/bin/cloud-init are supposed to run first, in sequence:

   cloud-init-local.service:
   Wants=local-fs.target
   After=local-fs.target

   cloud-init.service:
   After=local-fs.target network.target cloud-init-local.service
   Requires=network.target
   Wants=local-fs.target cloud-init-local.service

They then use a target to effect the equivalent of the upstart signal 
that cloud-init would normally emit at this point:

   cloud-config.target:
   Requires=cloud-init-local.service cloud-init.service

Note that targets are allowed to omit ordering dependencies.

Finally come the two services that run /usr/bin/cloud-init-cfg:

   cloud-config.service:
   After=network.target syslog.target cloud-config.target
   Requires=cloud-config.target
   Wants=network.target

   cloud-final.service:
   After=network.target syslog.target cloud-config.service rc-local.service
   Requires=cloud-config.target
   Wants=network.target

Given this dependency tree, I don't see how cloud-init.service could 
possibly start after cloud-config.service and cloud-final.service. 
Anyone have ideas?

[Michal Schmidt]

On 02/26/2012 07:37 AM, Garrett Holmstrom wrote:
>  On 2012-02-24 4:22, Juerg Haefliger wrote:
> > So I installed the official Fedora version of cloud-init but the
> > service startup ordering is broken there too:
> >
> > [root@342 ~]# dmesg | grep cloud | grep About
> > [   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init start-local
> > [   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
> > [   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final
> > [   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start 
I can't reproduce the problem. They are started in the expected order here.

Juerg,
is this a log of the order during boot? Or did you test the services by 
listing all 4 of them in systemctl start ...?
The latter would show bug 704214.

Michal

[Juerg Haefliger]

On Tue, Feb 28, 2012 at 12:02 PM, Michal Schmidt <mschmidt(a)redhat.com&gt; wrote:
>  On 02/26/2012 07:37 AM, Garrett Holmstrom wrote:
> >
> > On 2012-02-24 4:22, Juerg Haefliger wrote:
> >>
> >> So I installed the official Fedora version of cloud-init but the
> >> service startup ordering is broken there too:
> >>
> >> [root@342 ~]# dmesg | grep cloud | grep About
> >> [   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init
> >> start-local
> >> [   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
> >> config
> >> [   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
> >> final
> >> [   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start
>
>
>  I can't reproduce the problem. They are started in the expected order here.
>
>  Juerg,
>  is this a log of the order during boot? Or did you test the services by
>  listing all 4 of them in systemctl start ...?
>  The latter would show bug 704214. 

This is the boot order. Different than the last time:

[root@fedora ~]# dmesg | grep cloud
[    1.639947] systemd[1]: Installed new job cloud-config.service/start as 80
[    1.639952] systemd[1]: Installed new job cloud-config.target/start as 81
[    1.639957] systemd[1]: Installed new job
cloud-init-local.service/start as 82
[    1.639961] systemd[1]: Installed new job cloud-init.service/start as 83
[    1.639966] systemd[1]: Installed new job cloud-final.service/start as 84
[    1.640413] systemd[1]: cloud-config.target changed dead -> active
[    1.640426] systemd[1]: Job cloud-config.target/start finished, result=done
[   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init start-local
[   91.686093] systemd[1]: Forked /usr/bin/cloud-init as 489
[   91.686227] systemd[1]: cloud-init-local.service changed dead -> start
[   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
[   91.998048] systemd[1]: Forked /usr/bin/cloud-init-cfg as 549
[   91.998213] systemd[1]: cloud-config.service changed dead -> start
[   92.364807] systemd[1]: Received SIGCHLD from PID 549 (cloud-init-cfg).
[   92.364835] systemd[1]: Got SIGCHLD for process 549 (cloud-init-cfg)
[   92.364877] systemd[1]: Child 549 belongs to cloud-config.service
[   92.364889] systemd[1]: cloud-config.service: main process exited,
code=exited, status=0
[   92.375143] systemd[1]: cloud-config.service changed start -> exited
[   92.375160] systemd[1]: Job cloud-config.service/start finished, result=done
[   92.375264] systemd[1]: Got SIGCHLD for process 489 (cloud-init)
[   92.375302] systemd[1]: Child 489 belongs to cloud-init-local.service
[   92.375311] systemd[1]: cloud-init-local.service: main process
exited, code=exited, status=1
[   92.376121] systemd[1]: cloud-init-local.service changed start -> failed
[   92.377151] systemd[1]: Job cloud-init-local.service/start
finished, result=failed
[   92.377175] systemd[1]: Unit cloud-init-local.service entered failed state.
[   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
[   92.385184] systemd[1]: Forked /usr/bin/cloud-init as 599
[   92.385262] systemd[1]: cloud-init.service changed dead -> start
[   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final
[   92.393218] systemd[1]: Forked /usr/bin/cloud-init-cfg as 600
[   92.393358] systemd[1]: cloud-final.service changed dead -> start
[   92.394075] systemd[1]: cloud-config.service: cgroup is empty
[   92.394927] systemd[1]: cloud-init-local.service: cgroup is empty
[   92.550734] systemd[1]: Received SIGCHLD from PID 600 (cloud-init-cfg).
[   92.550760] systemd[1]: Got SIGCHLD for process 600 (cloud-init-cfg)
[   92.550803] systemd[1]: Child 600 belongs to cloud-final.service
[   92.550810] systemd[1]: cloud-final.service: main process exited,
code=exited, status=0
[   92.559058] systemd[1]: cloud-final.service changed start -> exited
[   92.559072] systemd[1]: Job cloud-final.service/start finished, result=done
[   92.559522] systemd[1]: cloud-final.service: cgroup is empty
[  116.415829] systemd[1]: Received SIGCHLD from PID 599 (cloud-init).
[  116.415854] systemd[1]: Got SIGCHLD for process 599 (cloud-init)
[  116.415896] systemd[1]: Child 599 belongs to cloud-init.service
[  116.415908] systemd[1]: cloud-init.service: main process exited,
code=exited, status=0
[  116.422236] systemd[1]: cloud-init.service changed start -> exited
[  116.422252] systemd[1]: Job cloud-init.service/start finished, result=done
[  116.422760] systemd[1]: cloud-init.service: cgroup is empty
[root@fedora ~]# dmesg | grep cloud | grep Ab
[   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init start-local
[   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
[   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
[   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final

Send me your public key and I'll hook you up with access to the VM if
you want to poke around.

...Juerg


>  Michal
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Garrett Holmstrom]

On Feb 28, 2012 6:12 AM, "Juerg Haefliger" <juergh(a)gmail.com&gt; wrote:
>  [   92.376121] systemd[1]: cloud-init-local.service changed start
> -> 
failed

Of interest here is the fact that the script that cloud-init-local.service
runs currently has a bug that causes it to return the wrong return code.
Since cloud-init.target Requires that service (cloud-config.service does
not function correctly without it), two of those services should not be
running at all, if I understand the systemd documentation correctly.
On Feb 28, 2012 6:12 AM, "Juerg Haefliger" <juergh(a)gmail.com&gt; wrote:

>  On Tue, Feb 28, 2012 at 12:02 PM, Michal Schmidt
> <mschmidt(a)redhat.com&gt;
>  wrote:
>  > On 02/26/2012 07:37 AM, Garrett Holmstrom wrote:
>  >>
>  >> On 2012-02-24 4:22, Juerg Haefliger wrote:
>  >>>
>  >>> So I installed the official Fedora version of cloud-init but the
>  >>> service startup ordering is broken there too:
>  >>>
>  >>> [root@342 ~]# dmesg | grep cloud | grep About
>  >>> [   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init
>  >>> start-local
>  >>> [   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg
>  all
>  >>> config
>  >>> [   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg
>  all
>  >>> final
>  >>> [   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start
>  >
>  >
>  > I can't reproduce the problem. They are started in the expected order
>  here.
>  >
>  > Juerg,
>  > is this a log of the order during boot? Or did you test the services by
>  > listing all 4 of them in systemctl start ...?
>  > The latter would show bug 704214.
>
>
>  This is the boot order. Different than the last time:
>
>  [root@fedora ~]# dmesg | grep cloud
>  [    1.639947] systemd[1]: Installed new job cloud-config.service/start as
>  80
>  [    1.639952] systemd[1]: Installed new job cloud-config.target/start as
>  81
>  [    1.639957] systemd[1]: Installed new job
>  cloud-init-local.service/start as 82
>  [    1.639961] systemd[1]: Installed new job cloud-init.service/start as 83
>  [    1.639966] systemd[1]: Installed new job cloud-final.service/start as
>  84
>  [    1.640413] systemd[1]: cloud-config.target changed dead -> active
>  [    1.640426] systemd[1]: Job cloud-config.target/start finished,
>  result=done
>  [   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init
>  start-local
>  [   91.686093] systemd[1]: Forked /usr/bin/cloud-init as 489
>  [   91.686227] systemd[1]: cloud-init-local.service changed dead -> start
>  [   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
>  config
>  [   91.998048] systemd[1]: Forked /usr/bin/cloud-init-cfg as 549
>  [   91.998213] systemd[1]: cloud-config.service changed dead -> start
>  [   92.364807] systemd[1]: Received SIGCHLD from PID 549 (cloud-init-cfg).
>  [   92.364835] systemd[1]: Got SIGCHLD for process 549 (cloud-init-cfg)
>  [   92.364877] systemd[1]: Child 549 belongs to cloud-config.service
>  [   92.364889] systemd[1]: cloud-config.service: main process exited,
>  code=exited, status=0
>  [   92.375143] systemd[1]: cloud-config.service changed start -> exited
>  [   92.375160] systemd[1]: Job cloud-config.service/start finished,
>  result=done
>  [   92.375264] systemd[1]: Got SIGCHLD for process 489 (cloud-init)
>  [   92.375302] systemd[1]: Child 489 belongs to cloud-init-local.service
>  [   92.375311] systemd[1]: cloud-init-local.service: main process
>  exited, code=exited, status=1
>  [   92.376121] systemd[1]: cloud-init-local.service changed start -> failed
>  [   92.377151] systemd[1]: Job cloud-init-local.service/start
>  finished, result=failed
>  [   92.377175] systemd[1]: Unit cloud-init-local.service entered failed
>  state.
>  [   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
>  [   92.385184] systemd[1]: Forked /usr/bin/cloud-init as 599
>  [   92.385262] systemd[1]: cloud-init.service changed dead -> start
>  [   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
>  final
>  [   92.393218] systemd[1]: Forked /usr/bin/cloud-init-cfg as 600
>  [   92.393358] systemd[1]: cloud-final.service changed dead -> start
>  [   92.394075] systemd[1]: cloud-config.service: cgroup is empty
>  [   92.394927] systemd[1]: cloud-init-local.service: cgroup is empty
>  [   92.550734] systemd[1]: Received SIGCHLD from PID 600 (cloud-init-cfg).
>  [   92.550760] systemd[1]: Got SIGCHLD for process 600 (cloud-init-cfg)
>  [   92.550803] systemd[1]: Child 600 belongs to cloud-final.service
>  [   92.550810] systemd[1]: cloud-final.service: main process exited,
>  code=exited, status=0
>  [   92.559058] systemd[1]: cloud-final.service changed start -> exited
>  [   92.559072] systemd[1]: Job cloud-final.service/start finished,
>  result=done
>  [   92.559522] systemd[1]: cloud-final.service: cgroup is empty
>  [  116.415829] systemd[1]: Received SIGCHLD from PID 599 (cloud-init).
>  [  116.415854] systemd[1]: Got SIGCHLD for process 599 (cloud-init)
>  [  116.415896] systemd[1]: Child 599 belongs to cloud-init.service
>  [  116.415908] systemd[1]: cloud-init.service: main process exited,
>  code=exited, status=0
>  [  116.422236] systemd[1]: cloud-init.service changed start -> exited
>  [  116.422252] systemd[1]: Job cloud-init.service/start finished,
>  result=done
>  [  116.422760] systemd[1]: cloud-init.service: cgroup is empty
>  [root@fedora ~]# dmesg | grep cloud | grep Ab
>  [   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init
>  start-local
>  [   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
>  config
>  [   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
>  [   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
>  final
>
>  Send me your public key and I'll hook you up with access to the VM if
>  you want to poke around.
>
>  ...Juerg
>
>
>  > Michal
>  >
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Michal Schmidt]

Dne 28.2.2012 17:23, Garrett Holmstrom napsal(a):
>  Of interest here is the fact that the script that
>  cloud-init-local.service runs currently has a bug that causes it to
>  return the wrong return code. Since cloud-init.target Requires that
>  service (cloud-config.service does not function correctly without it),
>  two of those services should not be running at all, if I understand the
>  systemd documentation correctly. 
Garrett,
Juerg had an old version of systemd installed (F16 GA, no updates).
After installing updates he's now getting dependency failures as you 
correctly anticipated :-)

[   97.114643] systemd[1]: cloud-init-local.service: main process
exited, code=exited, status=1
[   97.115478] systemd[1]: cloud-init-local.service changed start -> failed
[   97.124134] systemd[1]: Job cloud-init-local.service/start
finished, result=failed
[   97.124157] systemd[1]: Job cloud-config.target/start finished,
result=dependency
[   97.124173] systemd[1]: Job cloud-final.service/start finished,
result=dependency
[   97.124192] systemd[1]: Job cloud-final.service/start failed with
result 'dependency'.
[   97.124875] systemd[1]: Job cloud-config.service/start finished,
result=dependency
[   97.124894] systemd[1]: Job cloud-config.service/start failed with
result 'dependency'.
[   97.125595] systemd[1]: Job cloud-config.target/start failed with
result 'dependency'.