touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #111862
[Bug 1465386] Re: Default values for WAIT_STATE are wrong in the upstart wait-for-state job
Of course.
I actually only know two examples:
- mounting-glusterfs.conf: The glusterfs-client package uses the command "wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs" without passing "WAIT_STATE=running";
- So, this command doesn't works;
- See: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382 and https://bugzilla.redhat.com/show_bug.cgi?id=1231983;
- nova-compute.conf: The nova-compute package uses the comand wait-for-
state, but passes the WAIT_STATE=running option ("running", in my
opinion, should be the default instead of "started"):
# If libvirt-bin is installed, always wait for it to start first
if status libvirt-bin; then
start wait-for-state WAIT_FOR=libvirt-bin WAIT_STATE=running WAITER=nova-compute
fi
So, it works.
Again, in the link http://upstart.ubuntu.com/cookbook/#job-states, we
can sse that 'start/running' and 'stop/waiting' are the correct states,
and not the 'start/started' and 'stop/stopped'.
** Bug watch added: Red Hat Bugzilla #1231983
https://bugzilla.redhat.com/show_bug.cgi?id=1231983
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1465386
Title:
Default values for WAIT_STATE are wrong in the upstart wait-for-state
job
Status in upstart package in Ubuntu:
Incomplete
Bug description:
In Ubuntu 14.04, the wait-for-state job uses the env vars
WAIT_STATE="started" or WAIT_STATE="stopped". if the GOAL env var is
set to 'start' or 'stop'.
However, according to the upstart cookbook, the desired states for a
already started/stopped job are 'start/running' and 'stop/waiting'.
Maybe a misunderstood has occurred was the meaning of signals was job
states (for example, after a job reaches the start/running state, it
emits the started signal).
The strange thing is that the waiting/running wait states were
proposed at the first implementations of this job, and not the
stopped/started states: https://lists.ubuntu.com/archives/upstart-
devel/2011-February/001405.html.
This bug can make some developers to write upstart jobs that return
errors (like the GlusterFS developers, that forgot the
WAIT_STATE="running" condition).
References:
- http://upstart.ubuntu.com/cookbook/#job-states
- http://upstart.ubuntu.com/cookbook/#events-not-states
- https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1465382
I'm attaching a patch too.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1465386/+subscriptions
References