[OE-core] [PATCH v4 0/6] systemd patches

[Alex Kiernan]

On Thu, Jan 31, 2019 at 5:33 PM Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
>
> On Thu, 2019-01-31 at 14:19 +0100, Jonas Bonn wrote:
> [...]
> > So with that:
> >
> > a)  Does buildbot use connman, systemd-networkd, both, or something
> > else?  How do I find this out?
>
> We're building standard poky so there are no non-standard settings,
> other than for those images, enabling systemd. You can see the
> configuration and revisions used in the logs.
>
> On the host side, the autobuilders are configured with static tap
> devices which the user running the build has permissions for.
>
> > b)  I'll poke at the patch series again once I get a working
> > origin/master build so that I have sane state to work from.  The
> > systemd patches work fine on Thud... I suspect the problem lies
> > elsewhere.
> >
> > c)  Are others seeing similar errors with connman?
>
> Our builds work fine with current master, as soon as we add the patches
> they break. They break even with just the machineid changes. I haven't
> looked into why, I just know our regression tests go red with your
> patches :(.
>

Okay, I know what's going on... the issue is there's new services
enabled which weren't enabled previously, including
systemd-time-wait-sync.service which fails to activate because
systemd-timesyncd can never get time as we've no DNS server.
systemd-time-wait-sync.service then gets caught by the test for
"systemctl --state=activating" returning an empy list of units and our
test in settle() fails

The reason the machine-id change trips is because "systemctl
--preset-all" is now being run, which enables these services:

$ diff pass fail
0a1
> /etc/systemd/system/getty.target.wants/getty at tty1.service
2a4
> /etc/systemd/system/graphical.target.wants/console-kit-daemon.service
11a14
> /etc/systemd/system/multi-user.target.wants/machines.target
14a18,21
> /etc/systemd/system/multi-user.target.wants/remote-fs.target
> /etc/systemd/system/multi-user.target.wants/systemd-networkd.service
> /etc/systemd/system/multi-user.target.wants/systemd-resolved.service
> /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service
18a26,28
> /etc/systemd/system/sockets.target.wants/systemd-networkd.socket
> /etc/systemd/system/sysinit.target.wants/systemd-time-wait-sync.service
> /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service

Which shows the problem where I came into this - images using systemd
currently don't get systemd-networkd, which is unfortunate if you you
were using that for your networking.

If I compare the list of services with the systemd 242 changeset
reverted, the list is rather more reasonable:

$ diff pass.241 fail
3a4
> /etc/systemd/system/graphical.target.wants/console-kit-daemon.service
25a27
> /etc/systemd/system/sysinit.target.wants/systemd-time-wait-sync.service

If I disable just systemd-timesyncd.service with a hack in systemd:

$ git diff
diff --git a/presets/90-systemd.preset b/presets/90-systemd.preset
index 11960e54236a..75636134c835 100644
--- a/presets/90-systemd.preset
+++ b/presets/90-systemd.preset
@@ -18,6 +18,7 @@ enable getty at .service
 enable systemd-timesyncd.service
 enable systemd-networkd.service
 enable systemd-resolved.service
+disable systemd-time-wait-sync.service

 disable console-getty.service
 disable debug-shell.service

Then the tests work fine with systemd 242 and this (rebased) changeset.

What I've so far failed to figure out is why
systemd-time-wait-sync.service gets enabled since I can't find a
preset for it, and as far as I can tell it has to be coming from
systemd. There's https://github.com/systemd/systemd/issues/10253
(which is closed) in this space where there's a reference to
systemd-time-wait-sync.service in there getting enabled, so I think
this has to be coming from systemd.

I could post the rebased changeset with the above hack (which would
fix images expecting systemd-networkd), or wait whilst I dig into
systemd to figure out what's enabling systemd-time-wait-sync.service?

--
Alex Kiernan