So, I think there are three things we can do: 1) Make uvtool's postinst wait for libvirtd's unix socket to exist and be connectable. I think I should do this anyway as a workaround, as it's not particularly intrusive, will get us by for now and will help with the no-change backport to Precise I'd like to be possible without having to worry about a libvirt SRU. But it doesn't seem like a clean solution to me. I have a debdiff ready for this that uses socat, and another that uses a Python script to avoid a universe dependency in case we want to MIR uvtool in the future.
2) Modify libvirt's packaging to use "expect stop". I have an experimental debdiff that appears to work fine with this option and solves the original issue with no modification to uvtool's postinst needed. But it seems a bit ugly to me, since libvirt's behaviour in not existing the original called process before it is ready seems perfectly reasonable to me. 3) Make upstart wait on the original called process after it detects the fork with "expect daemon". Presumably this applies to "expect fork" as well. Is there any use case for which this isn't reasonable or would create a regression? Are there any other problems with this approach? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1228210 Title: libvirt-bin upstart job considers service "started" before it is ready To manage notifications about this bug go to: https://bugs.launchpad.net/uvtool/+bug/1228210/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
