Can't start virtual machines with installed systemd-container package on Xenial

Bug #1529079 reported by RussianNeuroMancer
66
This bug affects 10 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Invalid
High
Unassigned
Xenial
Invalid
Undecided
Unassigned
systemd (Fedora)
Won't Fix
High
systemd (Ubuntu)
Fix Released
Medium
Unassigned
Xenial
Fix Released
Undecided
Unassigned

Bug Description

Can't start virtual machines after upgrade to Xenial.

On Ubuntu Server 16.04:
# virsh start testserver
Cannot set property Before, or unknown property.

On Kubuntu 16.04:
Cannot set property Before, or unknown property.
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1873, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 414, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 478, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3585, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: Cannot set property Before, or unknown property.

At this moment there is no libvirt or systemd-related error messages in syslog when this error appear on the screen (or virsh output). Both systems was upgraded from 15.10.
---
ApportVersion: 2.19.3-0ubuntu2
Architecture: amd64
DistroRelease: Ubuntu 16.04
Package: libvirt (not installed)
ProcCmdline: BOOT_IMAGE=/@/boot/vmlinuz-4.3.3-040303-generic root=UUID=a100d974-72cf-44ad-acf8-6ec060b773dd ro rootflags=subvol=@Xenial quiet nomdmonddf nomdmonisw
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=C
 SHELL=/bin/bash
Tags: xenial
Uname: Linux 4.3.3-040303-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
modified.conffile..etc.libvirt.qemu.networks.default.xml: [modified]
mtime.conffile..etc.libvirt.qemu.networks.default.xml: 2015-02-27T11:49:59.773560

SRU INFORMATION
===============
Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial&id=5c4291769cb426a

Regression potential: This changes a central place of systemd (although the fix is quite obvious), so if that code is broken it could potentially lead to boot failure. However, the fix has been tested in yakkety, and all the time in upstrean and downstream CI, so if this would actually break anything it should have surfaced by now. So low overall.

Test case: Should be verified by the reporter as the bug description did not include a reproducer.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libvirt (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti)
no longer affects: systemd (Ubuntu)
Changed in libvirt (Ubuntu):
importance: Undecided → High
Revision history for this message
Chris J Arges (arges) wrote :

Please collect additional information and logs with 'apport-collect 1529079'. In addition having the XML file associated with the problematic VM may help. Please run 'virsh dumpxml testserver' and attach to this bug report.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : JournalErrors.txt

apport information

tags: added: apport-collected
description: updated
Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : KernLog.txt

apport information

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : RelatedPackageVersions.txt

apport information

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : Re: Can't start virtual machines after upgrade to Xenial

Seems like that won't be enough, so I'll upload two more files just in case:

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :
Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Could you attach the .xml for the vm?

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

Relevant quote from libvirt debug log:

2016-01-07 03:30:49.042+0000: 1177: info : virDBusCall:1548 : DBUS_METHOD_CALL: 'org.freedesktop.machine1.Manager.CreateMachineWithNetwork' on '/org/freedesktop/machine1' at 'org.freedesktop.machine1'
2016-01-07 03:30:49.088+0000: 1177: info : virDBusCall:1558 : DBUS_METHOD_ERROR: 'org.freedesktop.machine1.Manager.CreateMachineWithNetwork' on '/org/freedesktop/machine1' at 'org.freedesktop.machine1' error org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property Before, or unknown property.
2016-01-07 03:30:49.088+0000: 1177: error : virSystemdCreateMachine:291 : Cannot set property Before, or unknown property.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Running a simple vm per https://wiki.ubuntu.com/SergeHallyn_libvirtnest did not reproduce a failure.

I assume it's something that virt-manager added to the vm definition.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

Virtual machine xml example.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

> Running a simple vm per https://wiki.ubuntu.com/SergeHallyn_libvirtnest did not reproduce a failure.
I grab this xml, correct path to img and iso files, and enable network bridge...

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

...but issue is still reproducible with same error message. On this vm too.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Interesting, so that really seems to be a systemd-machined issue.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

I can add systemd again?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Oh, do you not have systemd installed?

Libvirt should be working falling back to non-systemd in that case, so it doesn't excuse the bug, but installing systemd might fix it for you.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

I have systemd installed.
I mean, I can add systemd package as affected package again?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1529079] Re: Can't start virtual machines after upgrade to Xenial

Quoting RussianNeuroMancer (<email address hidden>):
> I have systemd installed.
> I mean, I can add systemd package as affected package again?

Yes I think that's fair, though it's more likely a bug in libvirt's
use of systemd-machined.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : Re: Can't start virtual machines after upgrade to Xenial

> > I can add systemd package as affected package again?
> Yes I think that's fair, though it's more likely a bug in libvirt's use of systemd-machined.

Okay, I added systemd package as affected.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I still cannot reproduce this at all, even when starting VMs from virt-manager.

Are you still able to reproduce this? (I'm wondering whether perhaps there was a temporary bad state of systemd and libvirt being out of sync some magical way)

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I'm also curious why the launchpad janitor marked this bug confirmed. If anyone else can reproduce this issue, please comment here. Otherwise, I do not want it marked confirmed until someone truly independently reproduces it.

Changed in libvirt (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

> I still cannot reproduce this at all, even when starting VMs from virt-manager.
Well, for fresh install this is not reproducible for me too. And 15.10-16.04 upgrade may not be actual trigger - both testing systems get upgraded for a long time, Kubuntu from 11.04 as I remember. So there is may be something ancient that showed up just now. Or not so ancient - maybe some upstart->systemd upgrade issue. I have no idea actually what it may be. How I can help here find what's going on?

> Are you still able to reproduce this? (I'm wondering whether perhaps there was a temporary bad state of systemd and libvirt being out of sync some magical way)
Still reproducible on my testing Kubuntu 16.04 setup. I can try Ubuntu Server 15.10->16.04 upgrade once again, if necessary. Is it needed if issue still reproducible on updated Kubuntu 16.04?

Revision history for this message
Gannet (ken20001) wrote :

Hi, I had the same some time ago but then I went back to Wily.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1529079] Re: Can't start virtual machines after upgrade to Xenial

Quoting RussianNeuroMancer (<email address hidden>):
> > I still cannot reproduce this at all, even when starting VMs from virt-manager.
> Well, for fresh install this is not reproducible for me too. And 15.10-16.04
> upgrade may not be actual trigger - both testing systems get upgraded for a

And it is still reproducible after reboot after the upgrade, right?

> long time, Kubuntu from 11.04 as I remember. So there is may be something
> ancient that showed up just now. Or not so ancient - maybe some
> upstart->systemd upgrade issue. I have no idea actually what it may be. How I
> can help here find what's going on?
>
> > Are you still able to reproduce this? (I'm wondering whether perhaps there was a temporary bad state of systemd and libvirt being out of sync some magical way)
> Still reproducible on my testing Kubuntu 16.04 setup. I can try Ubuntu Server 15.10->16.04 upgrade once again, if necessary. Is it needed if issue still reproducible on updated Kubuntu 16.04?

I'll try the upgrade too. Thanks for the hint.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : Re: Can't start virtual machines after upgrade to Xenial

> And it is still reproducible after reboot after the upgrade, right?
Yes, this Kubuntu was rebooted yesterday after system upgrade.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1529079] Re: Can't start virtual machines after upgrade to Xenial

I installed Kubuntu 15.04, then distupgraded to 15.10 and 16.04, but was not able to reproduce this.

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote : Re: Can't start virtual machines after upgrade to Xenial

Please tell me how I can help you find root of this issue? As I said, reproducible for me on two installations (Kubuntu and Ubuntu Server).

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

Maybe error message from #12 and#16 provide any useful information?

Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

Issue is still reproducible on Kubuntu 16.04 with installed updates. I reproduced it with xml from commentary #15.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

Issue is still reproducible with latest version of libvirt package.

Changed in systemd (Ubuntu):
importance: Undecided → High
tags: added: rls-x-incoming
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

So I can reproduce this now that I've updated to xenial; smb and arges who did fresh installs cannot. Interesting.

Changed in libvirt (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Feb 17 13:13:19 sl libvirtd[9909]: DBUS_METHOD_CALL: 'org.freedesktop.machine1.Manager.CreateMachineWithNetwork' on '/org/freedesktop/machine1' at 'org.freedesktop.machine1'
Feb 17 13:13:19 sl libvirtd[9909]: DBUS_METHOD_ERROR: 'org.freedesktop.machine1.Manager.CreateMachineWithNetwork' on '/org/freedesktop/machine1' at 'org.freedesktop.machine1' error org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set pr
Feb 17 13:13:19 sl libvirtd[9909]: Cannot set property Before, or unknown property.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

The problem is introduced by systemd-machined, which is being provided by the systemd-container package.

The workaround is to apt-get purge systemd-container.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Lowering priority since there is a workaround.

Stilll not clear whether this is a bug in systemd-machined or in libvirt's use of it.

Changed in libvirt (Ubuntu):
importance: High → Medium
Changed in systemd (Ubuntu):
importance: High → Medium
summary: - Can't start virtual machines after upgrade to Xenial
+ Can't start virtual machines with installed systemd-container package on
+ Xenial
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

@pitti,

to reproduce in a fresh vm,

1. apt-get install qemu-kvm libvirt-bin
2. follow instructions at https://wiki.ubuntu.com/SergeHallyn_libvirtnest , in particular:
     a. wget http://people.canonical.com/~serge/cdboot.xml
     b. wget -O mini.iso http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/mini.iso
     c. qemu-img create cdboot.img 1G
     d. virsh define cdboot.xml
     e. virsh start cdboot
3. now apt-get install systemd-container

now virsh destroy cdboot; virsh start cdboot; it should fail

Revision history for this message
Martin Pitt (pitti) wrote :

The error message is pretty clear. src/util/virsystemd.c does

        if (virDBusCallMethod(conn,
                              NULL,
                              &error,
                              "org.freedesktop.machine1",
                              "/org/freedesktop/machine1",
                              "org.freedesktop.machine1.Manager",
                              "CreateMachineWithNetwork",
[...]
                            "After", "as", 1, "libvirtd.service",
                             "Before", "as", 1, "libvirt-guests.service") < 0) {

and these properties are unknown/invalid for machines. You can't specify an ordering dependency to an object that you create *right now*, as there is no way to enforce them. So just dropping these two lines ought to fix it.

(Also, it would be nice if a failure to register to machined wasn't fatal)

Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Changed in libvirt (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1529079] Re: Can't start virtual machines with installed systemd-container package on Xenial

Interesting. It is still this way in libvirt git HEAD.

Revision history for this message
Jérôme Poulin (jeromepoulin) wrote :

Well, until then...

virsh () { apt-get -qqy remove systemd-container >/dev/null; /usr/bin/virsh "$@"; apt-get -qqy install systemd-container >/dev/null; }

Changed in libvirt (Ubuntu):
importance: Medium → High
Revision history for this message
keshara Dorakumbura (krs4keshara) wrote :

Cannot start virtual machines via kvm once install 'systemd-container' package. I am on Ubuntu16.04-xenial.

Revision history for this message
Andrew Cooks (acooks) wrote :

I tried the fix suggested in #40, but couldn't get it to work.

[Wed, 08 Jun 2016 10:39:46 virt-install 23425] DEBUG (cli:305) File "/usr/share/virt-manager/virt-install", line 1063, in <module>
    sys.exit(main())
  File "/usr/share/virt-manager/virt-install", line 1057, in main
    start_install(guest, continue_inst, options)
  File "/usr/share/virt-manager/virt-install", line 768, in start_install
    fail(e, do_exit=False)
  File "/usr/share/virt-manager/virtinst/cli.py", line 305, in fail
    logging.debug("".join(traceback.format_stack()))

[Wed, 08 Jun 2016 10:39:46 virt-install 23425] ERROR (cli:306) End of file while reading data: Input/output error
[Wed, 08 Jun 2016 10:39:46 virt-install 23425] DEBUG (cli:308)
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-install", line 741, in start_install
    dom = guest.start_install(meter=meter, noboot=options.noreboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 501, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 416, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3606, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: End of file while reading data: Input/output error

I really need both systemd-container and libvirt to work.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Reminder - see comment #40 for the proposed fix.

The pertinent question is, given that that is upstream, why is this apparently not a problem for other systemd-based distros? How does it work in Fedora?

Revision history for this message
Mtl Alow (mtl-alow-deactivatedaccount) wrote :

We do experience that issue too on CoreOS. Until CoreOS 1010, it worked just fine (systemd v225), and afterwards (systemd v229), the issue is present.

The libvirt code mentioned above did not change since 2014. Therefore, it seems that a change to systemd between 225 and 229 generates that issue.

Not sure of the importance of that `Before` close there yet. I need to document myself more. We could try without it and see how it goes.

Revision history for this message
In , Quentin (quentin-redhat-bugs) wrote :

Description of problem:

libvirt's virSystemdCreateMachine (src/util/virsystemd.c) calls the systemd API `CreateMachineWithNetwork` via D-Bus to register machines. It works fine until systemd 225. However, with systemd 229, the `Before` property that is passed isn't accepted anymore and thus, makes the registration and creation of machines to fail.

Version-Release number of selected component (if applicable):

libvirt 1.2.17 (13.el7_2.5)
systemd 229 (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN)

Steps to Reproduce:

0. Get an Ubuntu Xenial VM
1. apt-get install qemu-kvm libvirt-bin
2. Follow instructions at https://wiki.ubuntu.com/SergeHallyn_libvirtnest , in particular:
     a. wget http://people.canonical.com/~serge/cdboot.xml
     b. wget -O mini.iso http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/mini.iso
     c. qemu-img create cdboot.img 1G
     d. virsh define cdboot.xml
     e. virsh start cdboot
3. now apt-get install systemd-container
4. now virsh destroy cdboot; virsh start cdboot; it should fail

(https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1529079/comments/39)

Actual results:

libvirtError: Cannot set property Before, or unknown property.

Expected results:

- The machine should be started properly:
     a. `Before` shouldn't be passed,
     b. `After` should probably not be passed either,
- A systemd registration failure should maybe not be critical.

Additional info:

Issue reproduced on Ubuntu Xenial & CoreOS >1010.

Revision history for this message
Daniel Berrange (berrange) wrote :

> You can't specify an ordering dependency to an object that you create *right now*, as there is no way to enforce them. So just dropping these two lines ought to fix it.

You're only considering startup ordering. These properties also apply to ordering when stopping units, and so these do make sense & are required to get correct shutdown ordering for machines.

Revision history for this message
Mtl Alow (mtl-alow-deactivatedaccount) wrote :

Just created an issue on libvirt's upstream bug tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1350909

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Passing Before & After properties is absolutely required in order to get correct shutdown ordering - ie we need systemd to run libvirt-guests.

I've confirmed testing on Fedora 24 with systemd 229 and see no failure, so I don't believe this is a libvirt bug. More likely it is a distro specific systemd bug or deployment mistake (eg perhaps missing libvirt-guests.service unit file).

Revision history for this message
Daniel Berrange (berrange) wrote :

> Not sure of the importance of that `Before` close there yet.

The Before/After properties provide the correct ordering of units on shutdown. Without this dependency, there is no guarantee that libvirt-guests.service will be invoked before systemd kills the machines, nor that it will keep libvirtd.service running until the VMs have been shutdown.

Revision history for this message
In , Michael (michael-redhat-bugs) wrote :

I haven't been able to spot anything in either the CoreOS or Fedora systemd patch sets that would impact this one way or the other so far, will need to dig further.

Revision history for this message
In , Michael (michael-redhat-bugs) wrote :

Ok, found some suspicious behavior in systemd. The distinction may be whether or not the 'After' dependency refers to an existing unit or not. On CoreOS it is entirely likely libvirtd.service doesn't exist or has a different name. I'm not sure about the Ubuntu case. Also the order if After/Before in the properties list is significant. Using Before/After appears to work.

Both dependencies do not exist, but fails only when After is first:

    # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \
        org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' \
        test7.slice replace 2 After as 1 other.target Before as 1 fake.target 0
    Cannot set property Before, or unknown property.

    # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \
        org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' \
        test7.slice replace 2 Before as 1 fake.target After as 1 other.target 0
    o "/org/freedesktop/systemd1/job/23660"

Whether or not the Before dependency exists never matters.

Quentin: so at least this hints at a workaround, either create a dummy libvirtd.service unit file or run the container with that unit name. Or if the container doesn't make sense to run as libvirtd.service maybe a unit alias is sufficient.

Alternate workaround: patch libvirt to swap the order of those two properties.

Real fix: figure out what on earth is going on in systemd, but that's all the brain power I can spend on this at the moment.

Revision history for this message
Michael Marineau (mike-marineau) wrote :

Is the libvirtd.service named differently on the Ubuntu system? I'm pretty sure this is a systemd bug, where if the properties list After first and After names a non-existent unit the Before property will fail. If After names an existing unit or Before is listed first it works. From https://bugzilla.redhat.com/show_bug.cgi?id=1350909#c3

    # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \
        org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' \
        test7.slice replace 2 After as 1 other.target Before as 1 fake.target 0
    Cannot set property Before, or unknown property.

    # busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \
        org.freedesktop.systemd1.Manager StartTransientUnit 'ssa(sv)a(sa(sv))' \
        test7.slice replace 2 Before as 1 fake.target After as 1 other.target 0
    o "/org/freedesktop/systemd1/job/23660"

Whether or not the Before dependency exists never matters.

Revision history for this message
Mtl Alow (mtl-alow-deactivatedaccount) wrote :

This issue happens to us because libvirt is being used inside a Docker container which share systemd with the host. Therefore, neither of these units exist on the host and as mentioned above, when a non-existing unit is specified in the `After` clause - listed first - the `Before` clause makes systemd fail.

Revision history for this message
In , Quentin (quentin-redhat-bugs) wrote :
Revision history for this message
In , Quentin (quentin-redhat-bugs) wrote :
Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Re-opening since F24 has the version of systemd with the flaw and so could benefit from the patch

Revision history for this message
Terra Nova (z-ububtu-t) wrote :

The fix has been merged into systemd via: https://github.com/systemd/systemd/pull/3676

It appears this was not a libvirt problem and the systemd 'invalid' tag is incorrect.

Has anyone already created a systemd issue to get it updated with this patch (I didn't find any)?

Revision history for this message
Martin Pitt (pitti) wrote :

Thanks! Moving this to the systemd package then. This commit is included in v231, so fixed in yakkety. I'll backport it to xenial.

Changed in libvirt (Ubuntu):
status: Triaged → Invalid
Changed in systemd (Ubuntu):
status: Invalid → Fix Released
Revision history for this message
Martin Pitt (pitti) wrote :

ps://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial&id=5c4291769c

Changed in systemd (Ubuntu Xenial):
status: New → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :
Changed in libvirt (Ubuntu Xenial):
status: New → Invalid
Revision history for this message
Andy Whitcroft (apw) wrote : Please test proposed package

Hello RussianNeuroMancer, or anyone else affected,

Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in systemd (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Martin Pitt (pitti)
description: updated
Revision history for this message
Jérôme Poulin (jeromepoulin) wrote :

The package that was submitted to xenial-proposed fixes the problem on my computer, machinectl start <container> and virsh start <qemu> can now be run without removing systemd-nspawn.

Martin Pitt (pitti)
tags: added: verification-done
removed: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote : Update Released

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package systemd - 229-4ubuntu8

---------------
systemd (229-4ubuntu8) xenial-proposed; urgency=medium

  * Queue loading transient units after setting their properties. Fixes
    starting VMs with libvirt. (LP: #1529079)
  * Connect pid1's stdin/out/err fds to /dev/null also for containers. This
    fixes generators which expect a valid stdout/err fd in some container
    technologies. (LP: #1608953)
  * 73-usb-net-by-mac.rules: Do not run readlink for *every* uevent, and
    merely check if /etc/udev/rules.d/80-net-setup-link.rules exists.
    A common way to disable an udev rule is to just "touch" it in
    /etc/udev/rule.d/ (i. e. empty file), and if the rule is customized we
    cannot really predict anyway if the user wants MAC-based USB net names or
    not. (LP: #1615021)
  * systemd-networkd-resolvconf-update.service: Also pick up DNS servers from
    individual link leases, as they sometimes don't appear in the global
    ifstate. (LP: #1620559)

 -- Martin Pitt <email address hidden> Tue, 06 Sep 2016 14:16:29 +0200

Changed in systemd (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
RussianNeuroMancer (russianneuromancer) wrote :

Thank you, Martin!

Revision history for this message
seahawk1986 (seahawk1986-hotmail) wrote :

Would it be possible to include this change to be able to receive all queued DBus signals from a unit before it is removed? https://github.com/systemd/systemd/commit/0dd99f86addd1f81e24e89807b6bc4aab57d5793

Tracking unit states using DBus signals has been working initially with Ubuntu 16.04 but does not work anymore for units that become inactive since the update of the systemd package in early september.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in systemd (Fedora):
importance: Unknown → High
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.