Hi Michael,
If I disable libvirtd, systemd-machined isn't started.
Can't say if this problem also occurs in Stretch - this is the only
machine with this configuration I have access to, and upgrading to
Stretch is on hold due to other considerations; I'll see if I can create
a similar environment to check, or failing that report back when it's
upgraded.
Regards,
John Pearson.
On 25/03/18 07:11, Michael Biebl wrote:
On Tue, 28 Mar 2017 07:39:58 +0200 Michael Biebl <bi...@debian.org> wrote:
Am 27.10.2016 um 23:13 schrieb John Pearson:
Hello Michael,
Thanks for looking at this.
On 22/10/16 11:07, Michael Biebl wrote:
Am 27.07.2016 um 02:59 schrieb John Pearson:
Hello Michael,
After the problem first occurred I reviewed bug #767468 and purged both
cgmanager and sytemd-shim, but the problem remained. And, of course,
/proc shows systemd-machined (and only systemd-machined) still "thought"
/nfs/home was mounted.
Why is systemd-machined running? Do you have any systemd-nspawn
containers running where /home is symlinked or bind-mounted?
I have no idea - it was installed as part of the systemd package, and
starts automatically at boot. The machine runs a single KVM instance
hosting Windows 7, managed by libvirtd.
If you stop systemd-machined, is the problem gone?
That seems to fix it without any obvious drawbacks, but I assume I'd
have to do the same after each reboot.
Is machined started by libvirtd then? What if you systemctl disable
libvirtd.service, does systemd-machined.service still start?
Can you reproduce the problem with stretch, i.e. with systemd v232?
Is this still reproducible with stretch?
--
*email:* j...@huiac.com
"The greatest shortcoming of the human race
is our inability to understand
the exponential function."
- Albert Allen Bartlett
*web:* http://www.huiac.com/
*mob:* +61 407 391 169
*phone:* +61 8 7127 6275
