Bug 623461 - systemctl start mdmonitor.service Job failed, see logs for details.
Summary: systemctl start mdmonitor.service Job failed, see logs for details.
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
(Show other bugs)
Version: 14
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-11 20:18 UTC by Nicolas Mailhot
Modified: 2011-03-25 18:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-25 18:43:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Nicolas Mailhot 2010-08-11 20:18:16 UTC
# setenforce permissive
# systemctl start mdmonitor.service
Job failed, see logs for details.


Aug 11 22:15:02  kernel: init[1]: mdmonitor.service: control process exited, code=exited status=6
Aug 11 22:15:02 arekh init[1]: mdmonitor.service: control process exited, code=exited status=6
Aug 11 22:15:02  init[1]: Unit mdmonitor.service entered maintenance state.
Aug 11 22:15:02  kernel: init[1]: Unit mdmonitor.service entered maintenance state.


mdadm-3.1.3-0.git20100804.2.fc14.x86_64
systemd-7-1.fc14.x86_64

Comment 1 Lennart Poettering 2010-08-12 02:46:37 UTC
So the service failed. But that's not a problem with systemd, that's just what mdonitor returned when it was started.

I see no problem here. And should there be one, then it is in mdmonitor, not systemd.

I think it would be smart if mdmonitor would be fixed to not start as part of the normal bootup, but by being pulled in via a device dependency from a udev/sysfs device. For example, something like this should do the job:

SUBSYSTEM=="block", KERNEL=="md*", TAG="systemd", ENV{SYSTEMD_WANTS}="mdmonitor.service"

If mdmonitor was started like that it would be activated only if an actual md device is around. That's of course good because we'd have to start less on non-md systems, the failed service wouldn't appear anymore in systemctl and even better simply configuring an md device will magically start mdmonitor.

Reassigning to mdmonitor.

Comment 2 Lennart Poettering 2010-09-13 10:15:36 UTC
Note that recent systemd versions will consider exit code 6 from LSB services OK, and will not mark them as failed. The main isue here goes away thus. The suggestion from comment 1 still apply however.

That siad, I'll take the liberty now to remove the F14target from this, since the main issue is gone by a systemd upload.

Comment 3 Nicolas Mailhot 2010-09-13 16:54:10 UTC
(In reply to comment #1)
> So the service failed. But that's not a problem with systemd, that's just what
> mdonitor returned when it was started.

The problem with this analysis is that the system the problem was reported on *has* a md raid to monitor (two in fact one for /boot and the other for everything else)

Comment 4 Michal Schmidt 2010-09-15 10:20:52 UTC
Having md arrays is not enough.
Does it have /etc/mdadm.conf? And are variables "MAILADDR" or "PROGRAM" set in the file? If not, mdmonitor has nothing to do and refuses to start.

Comment 5 Doug Ledford 2010-11-23 18:15:22 UTC
Indeed, if the /etc/mdadm.conf is not properly populated, the service will not start even if there are md raid arrays to monitor.  Can you please verify if the service starts properly given a proper mdadm.conf file?

Comment 6 Doug Ledford 2011-03-25 18:43:16 UTC
Closing due to inactivity and the fact that it appears to be resolved suitably anyway.


Note You need to log in before you can comment on or make changes to this bug.