[Bug 1220915] Re: Inserting a job into dependency is very cumbersome

Steve Langasek steve.langasek at canonical.com
Wed Oct 2 20:23:06 UTC 2013


The 'filesystem' and 'local-filesystem' events will NOT block in the way
you describe.  The current behavior is by design.

>From the previous bug, it was suggested that you start your job on
'mounted MOUNTPOINT=/' instead, which is an event that WILL block.  Did
you try this?

** Changed in: upstart (Ubuntu)
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1220915

Title:
  Inserting a job into dependency is very cumbersome

Status in “upstart” package in Ubuntu:
  Won't Fix

Bug description:
  This is somewhat related to Bug #591834. I tried the suggestion there
  but this does not work. I didn't care for 2 years for this issue but
  now I have both a new use case for it and I have found a workaround,
  so I can explain better what the problem is.

  I like the package flashybrid which allows very fine grained control
  what parts of the root filesystem are writeable. It works by mounting
  the root filesystem read-only and bind-mounting the changeable
  directories from a ram filesystem into the root directory.

  Mounting the root filesystem read-only ONLY works if

  . it is already mounted (which I can check with a dependency to "local-filesystems"
  . AND no process has an open file in the root filesystem in WRITE mode.

  The 2nd part is actually what causes the headaches. My workaround that I implemented is that I created
  /etc/init/XXX.override files for ALL .conf file that have a "start on local-filesystems" or "start on "filesystem"
  dependency which contains just a copy of the original "start on" clause, but "start on filesystem" is
  replaced by  "start on filesystem and stopped flashybrid" (and similar for "local-filesystems"). This 
  works now, but whenever later a new .conf file is added (e.g. by a new package), I will have to create
  an appropriate .override file again as described above.

  A good solution would be a solution that would allow me to make (in the flashybrid .conf file ONLY)
  a specification that I want to start AFTER "local-filesystems" (this I can do already) AND that all jobs
  that are waiting for "local-filesystems" or "filesystem" should IN ADDITION to their current clause
  also wait for "stopped flashybrid".

  It is important that this also works when jobs are added later.

  One possible implementation could be that it would be possible to "enhance" events, i.e. "local-filesystems"
  is only emitted when "stopped flashybrid" is also true. Another - less generic, but probably implementable
  without code changes in the core code - would be that the standard event scheme is enhanced with
  hooks (i.e. we would have  events like 'filesystems-pre' and 'filesystems-post' and by default a simple
  task which waits for filesystem-pre and immediately emits filesystem-post. By replacing that default task with
  the flashybrid task, I could achieve what I want (provided mountall emits only 'filesystems-pre' and
  all jobs would start on 'filesystems-post' only). 

  I am quite sure that you developers have further ideas.

  I know this is more like a feature request - but to me (as user of flashybrid) it is really a bug that
  I have to create so many .override files. With System-V init, this was much simpler.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1220915/+subscriptions



More information about the foundations-bugs mailing list