On Wed, 17.06.15 21:10, Goffredo Baroncelli ([email protected]) wrote: > > Well, /bin/mount is not a daemon, and it should not be one. > > My helper is not a deamon; you was correct the first time: it blocks > until all needed/enough devices are appeared. > Anyway this should not be different from mounting a nfs > filesystem. Even in this case the mount helper blocks until the > connection happened. The block time is not negligible, even tough > not long as a device timeout ...
Well, the mount tool doesn't wait for the network to be configured or so. It just waits for a response from the server. That's quite a difference. > > Well, it's not really ugly. I mean, if the state or properties of a > > device change, then udev should update its information about it, and > > that's done via a retrigger. We do that all the time already, for > > example when an existing loopback device gets a backing file assigned > > or removed. I am pretty sure that loopback case is very close to what > > you want to do here, hence retriggering (either from the kernel side, > > or from userspace), appears like an OK thing to do. > > What seems strange to me is that in this case the devices don't have changed > their status. > How this problem is managed in the md/dm raid cases ? md has a daemon mdmon to my knowledge. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
