[systemd-devel] Errorneous detection of degraded array

[Andrei Borzenkov]

On Mon, Jan 30, 2017 at 9:36 AM, NeilBrown <neilb at suse.com> wrote:
...
>>>>>
>>>>> systemd[1]: Created slice system-mdadm\x2dlast\x2dresort.slice.
>>>>> systemd[1]: Starting system-mdadm\x2dlast\x2dresort.slice.
>>>>> systemd[1]: Starting Activate md array even though degraded...
>>>>> systemd[1]: Stopped target Local File Systems.
>>>>> systemd[1]: Stopping Local File Systems.
>>>>> systemd[1]: Unmounting /share...
>>>>> systemd[1]: Stopped (with error) /dev/md0.
>>>
...
>
> The race is, I think, that one I mentioned.  If the md device is started
> before udev tells systemd to start the timer, the Conflicts dependencies
> goes the "wrong" way and stops the wrong thing.
>

>From the logs provided it is unclear whether it is *timer* or
*service*. If it is timer - I do not understand why it is started
exactly 30 seconds after device apparently appears. This would match
starting service.

Yet another case where system logging is hopelessly unfriendly for
troubleshooting :(

> It would be nice to be able to reliably stop the timer when the device
> starts, without risking having the device get stopped when the timer
> starts, but I don't think we can reliably do that.
>

Well, let's wait until we can get some more information about what happens.

> Changing the
>   Conflicts=sys-devices-virtual-block-%i.device
> lines to
>   ConditionPathExists=/sys/devices/virtual/block/%i
> might make the problem go away, without any negative consequences.
>

Ugly, but yes, may be this is the only way using current systemd.

> The primary purpose of having the 'Conflicts' directives was so that
> systemd wouldn't log
>   Starting Activate md array even though degraded
> after the array was successfully started.

This looks like cosmetic problem. What will happen if last resort
service is started when array is fully assembled? Will it do any harm?

> Hopefully it won't do that when the Condition fails.
>