On Mon, Jan 30, 2017 at 9:36 AM, NeilBrown <neilb@xxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
