Cheryl Jennings [2015-10-28 13:59 -0000]: > 2 - However, I thought adding in After=cloud-config.target would ensure > that it wouldn't start until after cloud-init completes?
Not really, I'm afraid. TL;DR: this doesn't work that way, is prone to deadlocks, and rather hard to understand. Long-winded explanation in case you care: If some target (or other unit) pulls in a service via Wants/Requires during boot, systemd has control over when it starts which unit, and the After= will order the units accordingly. But if you manually start that unit, *you* determine the startup time. The After= for a target without a Wants=/Requires= is by and large meaningless with manual start requests: If cloud-config.target is not started, then nothing has activated it yet, and After= is a noop (as it's only ordering, not dependency). OTOH, if the target is already started, then the After= is immediately satisfied. "systemctl start foo" actually *does* wait in the case that foo.service has an After=bar.service, and bar.service is in state "activating" (i. e. already scheduled to be started). But targets don't have that state, they are just a synchronization point for boot ordering and have no "activating" or Exec= themselves. Note that if systemctl start *would* wait for cloud-config.target to be started, you would have a deadlock: the runcmd would wait forever for cloud-config.target (as only then it could start your unit), but the target won't be started until your runcmds (and other cloud-init stuff) finishes -- but that cant't happen because you wait. So in summary: Such a command can always only ever be a no-op or a deadlock with a target. If you do need such a case, then you can run "systemctl start --no-block" to just queue the start of a unit without waiting for it to be started; this would break the deadlock in the correct way. > 3 - The recreate steps for this are: > - Bootstrap local env on wily (this won't create a container) Oh, it won't? I thought it would already (similar to the machine-0 on the cloud). For trusty I did get a "juju-trusty-lxc-template" container which I thought was the result of bootstrap; but apparently it just appeared too late and it actually was the result of "machine add" then? > - Deploy using the command: `juju deploy wily/ubuntu`. It may take some time before you see the container started as juju will download the image before starting the template container. Ah, this command works, thanks. I didn't reproduce the bug yet with my first run, but I do see that temp reboot unit in action. To avoid doubt, this happens while building juju-wily-lxc-template, *not* while cloning it to ubuntu-local-machine-1, right? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1509747 Title: Intermittent lxc failures on wily, juju-template-restart.service race condition To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1509747/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
