Re: [PATCH v1] tools/hotplug: systemd: Make dependency on Xen device nodes

[Leo Yan <leo.yan@xxxxxxxxxx>]

On Fri, Aug 25, 2023 at 09:37:58AM +0200, Erik Schilling wrote:

[...]

> > > > diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in 
> > > > b/tools/hotplug/Linux/systemd/xenstored.service.in
> > > > index 261077dc92..6e48cdb0e7 100644
> > > > --- a/tools/hotplug/Linux/systemd/xenstored.service.in
> > > > +++ b/tools/hotplug/Linux/systemd/xenstored.service.in
> > > > @@ -1,7 +1,7 @@
> > > >  [Unit]
> > > >  Description=The Xen xenstore
> > > > -Requires=proc-xen.mount
> > > > -After=proc-xen.mount
> > > > +Requires=proc-xen.mount dev-xen-gntdev.device
> > > > +After=proc-xen.mount dev-xen-gntdev.device
> > > 
> > > I must admit that I am a bit confused why this is enough... During our
> > > discussion on Slack, when you quoted from your rule it included
> > > `ENV{SYSTEMD_WANTS}="xenstored.service"`. Did you drop that during later
> > > development? Was there additional reasearch involved in dropping it?
> >
> > Yes, I dropped ENV{SYSTEMD_WANTS}="xenstored.service" and it works well
> > at my side.
> 
> Hm. Interesting. Could you plot the activations after boot?
> 
>     systemd-analyze plot > /tmp/plot.svg
> 
> Seeing failure vs success but also the success cases on AVA vs Telechips
> may be interesting.
> 
> I just did some tests on my workstation where I added dependencies on
> a random USB device. If that one was not plugged at all, the service
> still happily started. Yet, it obviously seems to do something in your
> case... So I fear we may not fully understand the real problem yet.
> 
> I must admit that I find this case a bit under-documented. While "Wants"
> explicitly says that failling transactions are ignored, there is no
> clear statement about what happens in that case with "Requires".
> 
> While skimming the docs I also realized that maybe BindsTo= would maybe
> be more suitable compared to Requires= here. But that is unrelated to
> the confusion that I have about the original problem.

Please ignore this patch and sorry for noise.

Erik and me confirmed the systemd has established the dependencies
properly.  The dependency is (the above one depends on the blow one):

  xenstored.service
    `> sysinit.target
         `> systemd-modules-load.service (Load xen modules)


My issue is caused by a local customzied systemd-modules-load.service
which breaks the dependency between sysinit.target and
systemd-modules-load.service.

Very appreciate Erik's help for root cause the issue.

Thanks,
Leo