The ipmid failed to start

The ipmid failed to start

[P. K. Lee (李柏寬)]

Hi Brad,

I saw the issue, which is "recipes-phosphor: Fix systemd unit dependences of ipmid, mboxd" appending "Requires=org.openbmc.HostIpmi.service" and "Afteorg.openbmc.HostIpmi.service", you merged on Nov 29.

After that, the ipmid failed to start.

Because the file meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-kcs/org.openbmc.HostIpmi.service already included "After=phosphor-ipmi-host.service" before, it caused two services waiting for each other.

If the "Requires=org.openbmc.HostIpmi.service" and "Afteorg.openbmc.HostIpmi.service" are removed in the meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-host/phosphor-ipmi-host.service or the "After=phosphor-ipmi-host.service" is removed in the meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-kcs/org.openbmc.HostIpmi.service, the ipmid will start normally.

I wonder if there is a better way to go about it.

By the way, after I pushed the code to the Gerrit, "Jenkins Patch Set 1: User not approved, see admin, no CI" it showed. How can I solve this problem?

Sincerely,
P. K. Lee

Re: The ipmid failed to start

[Andrew Jeffery]

Hello,

On Mon, 10 Dec 2018, at 14:33, P. K. Lee (李柏寬) wrote:
> Hi Brad,
> 
> I saw the issue, which is "recipes-phosphor: Fix systemd unit 
> dependences of ipmid, mboxd" appending 
> "Requires=org.openbmc.HostIpmi.service" and 
> "Afteorg.openbmc.HostIpmi.service", you merged on Nov 29.
> 
> After that, the ipmid failed to start.
> 
> Because the file meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-kcs/
> org.openbmc.HostIpmi.service already included "After=phosphor-ipmi-
> host.service" before, it caused two services waiting for each other.

Ah, KCS. This is why I didn't hit the problem in my testing.

> 
> If the "Requires=org.openbmc.HostIpmi.service" and 
> "Afteorg.openbmc.HostIpmi.service" are removed in the meta-phosphor/
> recipes-phosphor/ipmi/phosphor-ipmi-host/phosphor-ipmi-host.service or 
> the "After=phosphor-ipmi-host.service" is removed in the meta-phosphor/
> recipes-phosphor/ipmi/phosphor-ipmi-kcs/org.openbmc.HostIpmi.service, 
> the ipmid will start normally.
> 
> I wonder if there is a better way to go about it.

It's a bit dicey. Something to consider here is that systemd does it's tear-down in stack-order with respect to the Before=/After= relationships defined in the service files. With org.openbmc.HostIpmi.service having an After= relationship with phosphor-ipmi-host.service it is torn down before phosphor-ipmi-host. This impacts processes that want to send events to the host during the BMC shutdown path: These applications need to depend on phosphor-ipmi-host to access its APIs, and it's a layering violation for the applications to also depend on the transport that phosphor-ipmi-host is using (KCS, BT etc). In order to propagate the event to the host, phosphor-ipmi-host needs its transport, and therefore must have an After= relationship with the transport process due to systemd's stack ordering on tear-down.

Having said that, requiring that After= relationship means that phosphor-ipmi-host.service is started after org.openbmc.HostIpmi.service, which means messages that arrive in the period between the two starting may get lost. I think it's worth keeping in mind that org.openbmc.HostIpmi simply emits a signal when a message is received, and this provides no guarantee of anyone actually caring. This is in contrast to sending events the other way, where org.openbmc.HostIpmi's interface provides a DBus method, which guarantees someone cares or the caller receives an error. This design fits the After= relationship that I made phosphor-ipmi-host have on org.openbmc.HostIpmi.service, so I'd suggest it's worth changing the relationship for the KCS implementation as well.

However, maybe that's a decision to be made per-platform rather than generally. I guess the unit files can be overridden in the packaging if this is a concern?

> 
> By the way, after I pushed the code to the Gerrit, "Jenkins Patch Set 1: 
> User not approved, see admin, no CI" it showed. How can I solve this 
> problem?

You need to convince someone that your patch isn't going to exploit our CI infrastructure :) Once you've earned some trust in the community with your contributions generally someone will add you to the list that allows CI to test your patches straight away.

Cheers,

Andrew

> 
> Sincerely,
> P. K. Lee

Re: The ipmid failed to start

[P. K. Lee (李柏寬)]

Hi Andrew,

Thanks for your explanations in details.

The current situation of starting KCS:
    systemd[1]: phosphor-ipmi-host.service: Found ordering cycle on org.openbmc.HostIpmi.service/start
    systemd[1]: phosphor-ipmi-host.service: Found dependency on phosphor-ipmi-host.service/start
    systemd[1]: phosphor-ipmi-host.service: Job org.openbmc.HostIpmi.service/start deleted to break ordering cycle starting with phosphor-ipmi-host.service/start

I will first remove After=phosphor-ipmi-host.service in org.openbmc.HostIpmi.service of phosphor-ipmi-kcs like BT.

Thanks,

P. K. Lee

> On Dec 11, 2018, at 08:35, Andrew Jeffery <andrew@aj.id.au> wrote:
> 
> Hello,
> 
> On Mon, 10 Dec 2018, at 14:33, P. K. Lee (李柏寬) wrote:
>> Hi Brad,
>> 
>> I saw the issue, which is "recipes-phosphor: Fix systemd unit 
>> dependences of ipmid, mboxd" appending 
>> "Requires=org.openbmc.HostIpmi.service" and 
>> "Afteorg.openbmc.HostIpmi.service", you merged on Nov 29.
>> 
>> After that, the ipmid failed to start.
>> 
>> Because the file meta-phosphor/recipes-phosphor/ipmi/phosphor-ipmi-kcs/
>> org.openbmc.HostIpmi.service already included "After=phosphor-ipmi-
>> host.service" before, it caused two services waiting for each other.
> 
> Ah, KCS. This is why I didn't hit the problem in my testing.
> 
>> 
>> If the "Requires=org.openbmc.HostIpmi.service" and 
>> "Afteorg.openbmc.HostIpmi.service" are removed in the meta-phosphor/
>> recipes-phosphor/ipmi/phosphor-ipmi-host/phosphor-ipmi-host.service or 
>> the "After=phosphor-ipmi-host.service" is removed in the meta-phosphor/
>> recipes-phosphor/ipmi/phosphor-ipmi-kcs/org.openbmc.HostIpmi.service, 
>> the ipmid will start normally.
>> 
>> I wonder if there is a better way to go about it.
> 
> It's a bit dicey. Something to consider here is that systemd does it's tear-down in stack-order with respect to the Before=/After= relationships defined in the service files. With org.openbmc.HostIpmi.service having an After= relationship with phosphor-ipmi-host.service it is torn down before phosphor-ipmi-host. This impacts processes that want to send events to the host during the BMC shutdown path: These applications need to depend on phosphor-ipmi-host to access its APIs, and it's a layering violation for the applications to also depend on the transport that phosphor-ipmi-host is using (KCS, BT etc). In order to propagate the event to the host, phosphor-ipmi-host needs its transport, and therefore must have an After= relationship with the transport process due to systemd's stack ordering on tear-down.
> 
> Having said that, requiring that After= relationship means that phosphor-ipmi-host.service is started after org.openbmc.HostIpmi.service, which means messages that arrive in the period between the two starting may get lost. I think it's worth keeping in mind that org.openbmc.HostIpmi simply emits a signal when a message is received, and this provides no guarantee of anyone actually caring. This is in contrast to sending events the other way, where org.openbmc.HostIpmi's interface provides a DBus method, which guarantees someone cares or the caller receives an error. This design fits the After= relationship that I made phosphor-ipmi-host have on org.openbmc.HostIpmi.service, so I'd suggest it's worth changing the relationship for the KCS implementation as well.
> 
> However, maybe that's a decision to be made per-platform rather than generally. I guess the unit files can be overridden in the packaging if this is a concern?
> 
>> 
>> By the way, after I pushed the code to the Gerrit, "Jenkins Patch Set 1: 
>> User not approved, see admin, no CI" it showed. How can I solve this 
>> problem?
> 
> You need to convince someone that your patch isn't going to exploit our CI infrastructure :) Once you've earned some trust in the community with your contributions generally someone will add you to the list that allows CI to test your patches straight away.
> 
> Cheers,
> 
> Andrew
> 
>> 
>> Sincerely,
>> P. K. Lee