[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