Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mboxd: 'Unknown lvalue' warnings for Wants and After directives #999

Closed
amboar opened this issue Jan 23, 2017 · 5 comments
Closed

mboxd: 'Unknown lvalue' warnings for Wants and After directives #999

amboar opened this issue Jan 23, 2017 · 5 comments

Comments

@amboar
Copy link
Member

amboar commented Jan 23, 2017

Discovered in the logs by @spinler:

Jan 20 22:11:29 zaius systemd[1]: Reloading.
Jan 20 22:11:30 zaius systemd[1]: [/lib/systemd/system/mboxd.service:7] Unknown lvalue 'Wants' in section 'Service'
Jan 20 22:11:30 zaius systemd[1]: [/lib/systemd/system/mboxd.service:8] Unknown lvalue 'After' in section 'Service'

This could be caused by the directives appearing in the wrong section of the unit file.

@vishwabmc
Copy link
Contributor

Wants=op-wait-power-off@%i.service
After=op-wait-power-off@%i.service

Should those be mapper-wait instead ?.

@spinler
Copy link
Contributor

spinler commented Jan 23, 2017

@vishwabmc What are you referring to?

@spinler
Copy link
Contributor

spinler commented Jan 23, 2017

@amboar Are you planning on fixing this yourself?

@amboar
Copy link
Member Author

amboar commented Jan 23, 2017

@spinler yes, I'll clean it up today

@amboar
Copy link
Member Author

amboar commented Jan 25, 2017

Patches are in gerrit: https://gerrit.openbmc-project.xyz/#/q/topic:mboxd-service

williamspatrick pushed a commit that referenced this issue Jan 25, 2017
At least one bug prevented the discovery that the udev rule was broken,
mainly that the Wants/After directives were in the wrong section of the
systemd unit file[1]. systemd logged and ignored the broken Wants/After
directives and launched the service anyway, which lead to the
impression that everthing was working as expected.

Fix the problem by inspecting the device with udevdm to determine it's
properties:

    $ udevadm info -q all -a /dev/aspeed-mbox`:

      looking at device '/devices/platform/ahb/1e789000.lpc/1e789080.lpc-host/1e789200.mbox/misc/aspeed-mbox':
        KERNEL=="aspeed-mbox"
        SUBSYSTEM=="misc"
        DRIVER==""
    ...

[1] #999

Change-Id: I91c410da44224ee7b5c527ee4a744b7e7ecd5a9b
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
@amboar amboar closed this as completed Jan 27, 2017
williamspatrick pushed a commit to openbmc/meta-phosphor that referenced this issue Jun 30, 2017
At least one bug prevented the discovery that the udev rule was broken,
mainly that the Wants/After directives were in the wrong section of the
systemd unit file[1]. systemd logged and ignored the broken Wants/After
directives and launched the service anyway, which lead to the
impression that everthing was working as expected.

Fix the problem by inspecting the device with udevdm to determine it's
properties:

    $ udevadm info -q all -a /dev/aspeed-mbox`:

      looking at device '/devices/platform/ahb/1e789000.lpc/1e789080.lpc-host/1e789200.mbox/misc/aspeed-mbox':
        KERNEL=="aspeed-mbox"
        SUBSYSTEM=="misc"
        DRIVER==""
    ...

[1] openbmc/openbmc#999

Change-Id: I91c410da44224ee7b5c527ee4a744b7e7ecd5a9b
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants