This bug was fixed in the package init-system-helpers - 1.29ubuntu3
---
init-system-helpers (1.29ubuntu3) xenial-proposed; urgency=medium
* invoke-rc.d, service: Only ignore systemd unit dependencies before
multi-user.target. "systemctl is-system-running" might still be false
** Description changed:
in cloud-init users can install packages via cloud-config:
#cloud-config
packages: [apache2]
Due to some intricacies of systemd and service installation that doesn't work
all that well.
We fixed the issue for simple services that do not have any dependencies
This bug was fixed in the package cloud-init -
0.7.8-1-g3705bb5-0ubuntu1~16.04.1
---
cloud-init (0.7.8-1-g3705bb5-0ubuntu1~16.04.1) xenial-proposed; urgency=medium
* New upstream release 0.7.8.
* New upstream snapshot.
- systemd: put cloud-init.target After multi-user.target
verified with:
printf "#cloud-config\npackages: [postgresql, samba, postfix]\n" > user-data
n=x1
lxc launch ubuntu-daily:xenial $n
sleep 10
lxc exec $n -- sh -c '
p=/etc/apt/sources.list.d/proposed.list
echo deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main
> "$p" &&
** Description changed:
in cloud-init users can install packages via cloud-config:
#cloud-config
packages: [apache2]
Due to some intricacies of systemd and service installation that doesn't work
all that well.
We fixed the issue for simple services that do not have any dependencies
Hello Scott, or anyone else affected,
Accepted cloud-init into xenial-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/cloud-
init/0.7.8-1-g3705bb5-0ubuntu1~16.04.1 in a few hours, and then in the
-proposed repository.
Please help us by testing this
** Description changed:
in cloud-init users can install packages via cloud-config:
#cloud-config
packages: [apache2]
Due to some intricacies of systemd and service installation that doesn't work
all that well.
We fixed the issue for simple services that do not have any dependencies
I just filed bug 1623868 which is fallout from this change, so blocking
this SRU for now.
** Tags removed: verification-done
** Tags added: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package installation in systemd
To manage
Thank you Neil!
I've been going through my testing here, and found:
* bug 1623570: Azure: cannot start walinux agent (Transaction order is cyclic.)
That will require us to get that fix in and through proposed or we will
break Azure boot. Its fallout of the systemd ordering.
** Description
Added both cloud-ini t and init-system-helpers from proposed to the
standard Xenial cloud image
(com.ubuntu.cloud:released:download/com.ubuntu.cloud:server:16.04:amd64/20160907.1/disk1.img)
on a suitably sized server.
Reset the cloud init with rm -rf /var/lib/cloud/instances/*, shutdown
the
Hello Scott, or anyone else affected,
Accepted init-system-helpers into xenial-proposed. The package will
build now and be available at https://launchpad.net/ubuntu/+source/init-
system-helpers/1.29ubuntu3 in a few hours, and then in the -proposed
repository.
Please help us by testing this new
init-system-helpers is still sitting in the SRU queue and needs to be
reviewed/accepted.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package installation in systemd
Have we back ported the init-system-helpers changes to Xenial?
I'm only seeing 1.29ubuntu2 this morning.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package
Hello Scott, or anyone else affected,
Accepted cloud-init into xenial-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/cloud-init/0.7.7-31
-g65ace7b-0ubuntu1~16.04.1 in a few hours, and then in the -proposed
repository.
Please help us by testing this
This bug was fixed in the package init-system-helpers - 1.44
---
init-system-helpers (1.44) unstable; urgency=medium
* invoke-rc.d, service: Check for multi-user.target instead of
graphical.target.
There is a curious bug which sometimes causes "systemctl is-active
We use what's in the archive for what we include in cloud images. So
once cloud-init lands, it will makes it way to an image. I would expect
that Scott working his way through the SRU process.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
@smoser
Did you commit your changes to the xenial cloud-init as well? I'm not
sure where xenial images grab cloud init for themselves, but I assume
out of the xenial archives. Am I missing something here?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Changed in: cloud-init (Ubuntu Xenial)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package installation in systemd
To
fixed in 0.7.8.
** Changed in: cloud-init
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package installation in systemd
To
Martin,
I moved all things that do package installation into final. The user could
still manage to have some things run at 'config' point in boot that would
install packages, but anything that does it in cloud-init directly is now part
of final.
--
You received this bug notification because
i-s-h SRU uploaded.
** Description changed:
in cloud-init users can install packages via cloud-config:
#cloud-config
packages: [apache2]
Due to some intricacies of systemd and service installation that doesn't work
all that well.
We fixed the issue for simple services that do not
https://anonscm.debian.org/cgit/collab-maint/init-system-
helpers.git/commit/?id=1460d6a02
I also committed https://anonscm.debian.org/cgit/collab-maint/init-
system-helpers.git/commit/?id=9cfb6dfed to further robustify the
behaviour, but it is not required to fix this bug.
** Changed in:
** Description changed:
in cloud-init users can install packages via cloud-config:
#cloud-config
packages: [apache2]
Due to some intricacies of systemd and service installation that doesn't work
all that well.
We fixed the issue for simple services that do not have any dependencies
@Scott: Oh, does that actually work with adding the After= to just
cloud-final.service? I thought the thing that *actually* does the
package installs is cloud-config.service, and this needed that After= as
well?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Just a comment / status here.
cloud-init is now running the modules that do package installation after
multi-user.target. the plan is to change init-system-helpers as pitti
described in comment 10. Until that is fixed, the problem isn't really fixed.
--
You received this bug notification
This bug was fixed in the package cloud-init -
0.7.7-28-g34a26f7-0ubuntu1
---
cloud-init (0.7.7-28-g34a26f7-0ubuntu1) yakkety; urgency=medium
* New upstream snapshot.
- systemd: Better support package and upgrade.
(LP: #1576692, #1621336)
- tests: cleanup tempdirs in
** Changed in: init-system-helpers (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: init-system-helpers (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: cloud-init (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Xenial)
For invoke-rc.d: original commit https://anonscm.debian.org/cgit/collab-
maint/sysvinit.git/commit/?id=38e2b9fca
Try to reproduce the hangs in https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=777113 when completely removing the hack, then
ensure that they go away again with is-active m-u.target
Change invoke-rc.d to check is-active multi-user.target instead of
is-system-running, to match After=multi-user.target.
Also, always use --no-block for reload as an additional line of defence for
if-up.d/ scripts, as reload has never been synchronous.
** Also affects: init-system-helpers
> Add multi-user.target to cloud-{config,final}.service
Sorry, I meant to add After=multi-user.target
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package
Pre-weekend braindump: I've had success with modifying a xenial image
like that:
/usr/sbin/invoke-rc.d:
if ! systemctl --quiet is-active default.target; then
sctl_args="--job-mode=ignore-dependencies"
fi
Add multi-user.target to
** Merge proposal linked:
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/305335
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package
Type=idle not waiting for running *.device jobs is related, but not
identical to bug 1620780. I filed that as bug 1621846. Those are both on
the systemd side, and for the cases where bug 1620780 does not hit (and
thus bug 1621846 does not happen), it has been demonstrated that moving
these units
Scott and I debugged this further, and the best hint so far is bug
1620780. In Scott's local instances he gets "systemctl is-system-
running" == "starting" with
JOB UNITTYPE STATE
2 dev-sda2.device start running
postgresql-9.5.postinst calls "invoke-rc.d postgresql start", and
I cannot see failed containers in your cloud instance, nor reproduce the
failure by starting new ones.
I have also created and run http://people.canonical.com/~pitti/tmp/psql-
idle.sh on my laptop and your cloud instance for 40 iterations, and I
couldn't reproduce a failure. This takes cloud-init
The bit that I have doubts about in https://git.launchpad.net/~smoser
/cloud-init/commit/?h=bug/1576692=6a249689a179f is why "runcmd" still
runs in cloud_config_modules -- it's arbitrary code which might (and
often does) run package installs, so it should really live in
cloud_final_modules as
I have a branch at
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/bug/1576692
which:
a.) moves cloud-init-final to be Type=idle
b.) moves config modules such as package-update-upgrade-install to run in the
final_modules
I've patched a lxc container with that, and then
It's worth mentioning the scope of the package upgrade/install issue
related to systemd.
For packages like apache2 which do not use dependent systemd service
files, those service packages install and start properly.
For packages with dependent service files, like postgresql (it has both
a
** Description changed:
in cloud-init users can install packages via cloud-config:
#cloud-config
packages: [apache2]
Due to some intricacies of systemd and service installation that doesn't work
all that well.
We fixed the issue for simple services that do not have any dependencies
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully support package installation in systemd
To manage notifications about this bug go to:
** Changed in: cloud-init (Ubuntu)
Importance: Medium => Critical
** Changed in: cloud-init
Importance: Medium => Critical
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576692
Title:
fully
An update to this, I think for the moment the plan is to move many of
the config modules that run in 'config_modules' to 'final_modules' and
to move final_modules to run as idle.
I dont love it, but it seems like the only actual path to package
installation to work.
--
You received this bug
Martin,
Probably worth noting that this impacts upon the configuration systems
as well. I'm using the PostgreSQL puppet configuration system, and that
will sit in a loop waiting for PostgresQL to come up before moving onto
the next stage of the configuration.
So if you are using puppet within
Would it be possible to move package installation into a cloud-
init-*.service that is "Type=idle", i. e. runs after booting is
complete? This would avoid all these corner cases and breakage when
trying to install/start things while booting is not complete yet.
** Description changed:
in
45 matches
Mail list logo
