On Mon, May 27, 2013 at 11:58:13AM -0700, Nikolaus Rath wrote: > The only way to avoid this (at least at the time I reported the bug), > would have been to recompile mountall to emit events with --no-wait (but > I'm not sure what other unintended consequences that would have had).
Lots of them. There are various actions one wants to take as soon as a filesystem is mounted, and before anything else is allowed to use the filesystem - tmp cleaning, for instance, or populating heirarchies on /run. Jobs starting on such 'mounted' events *must* block until they're finished, so that you don't have one part of the system racing to use /tmp while another part is still cleaning it. This is the primary purpose for which these 'mounted' events are made available. > As I said, there isn't a bug anywhere here. Once you understand what's > going on, this all makes sense. But I don't consider this a very good > design. Well, I don't think it's a bad design that third-party jobs can see and use upstart events that were created primarily for internal consumption; if anything, the problem is in documenting these in a way that doesn't make it clear that they are not a general-purpose interface for services and should not be used except in special cases. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
