On 03/27/2015 06:58 AM, Benjamin Marzinski wrote: > On Mon, Mar 16, 2015 at 01:37:04PM +0100, Hannes Reinecke wrote: >> For initial configuration multipathd waits it has synchronized >> with the existing setup. On larger systems this takes up quite >> some time (I've measured 80 seconds on a system with 1024 paths) >> causing systemd to stall and the system to fail booting. >> This patch makes the initial configuration asynchronous, and >> using the same codepath as the existing 'reconfigure' CLI >> command. > > If the issue is that configure takes too long, and is keeping multipath > from resetting the watchdog timer, can't this problem still happen? > > reconfigure still is called under the vecs lock, and checkerloop still > locks the vecs lock, so a call to reconfigure can still stall the > checker loop for just as long. > > Or am I missing something? The problem here is that on large configurations multipathd might spend too much time in configure(), so the sd_notify() call with 'RUNNING' is would be later than the default systemd service timeout. Hence multipathd will be killed by systemd with a job timeout, with no chance to get it to run, ever. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
