Quoting Wessel Dankers (<email address hidden>):
> What I'm seeing is a vgchange process that hangs until udev kills it.
> When it is killed it has only initialized a few LV's and most symlinks
> in /dev/<vgname> are missing. Perhaps this is a different bug, but the
> symptoms are exactly those from the original bug report.
>
> Also, I'm not preventing udev's exit from blocking on the vgchange
> completing but rather the reverse: I'm preventing vgchange's completing
> to block on udev.
Right, with that I was referring to my earlier solution of daemonizing
watershed. But,
> >From what I understand, vgchange waits for udev to finish processing the
> new device nodes before returning to the user so that after the command
> completes, the user can be sure that the nodes are created. Only in this
> case udev *is* the user, so it doesn't make sense to wait, and in fact
> creates a deadlock.
If that is the only point of the sync, then your solution is the best
one.
Quoting Wessel Dankers (<email address hidden>):
> What I'm seeing is a vgchange process that hangs until udev kills it.
> When it is killed it has only initialized a few LV's and most symlinks
> in /dev/<vgname> are missing. Perhaps this is a different bug, but the
> symptoms are exactly those from the original bug report.
>
> Also, I'm not preventing udev's exit from blocking on the vgchange
> completing but rather the reverse: I'm preventing vgchange's completing
> to block on udev.
Right, with that I was referring to my earlier solution of daemonizing
watershed. But,
> >From what I understand, vgchange waits for udev to finish processing the
> new device nodes before returning to the user so that after the command
> completes, the user can be sure that the nodes are created. Only in this
> case udev *is* the user, so it doesn't make sense to wait, and in fact
> creates a deadlock.
If that is the only point of the sync, then your solution is the best
one.
Thanks for your input, Wessel.