Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Dependency woe #27
Comments
ghost
assigned
saz
Dec 28, 2012
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
saz
Dec 28, 2012
Contributor
I think the only way to fix this, is a change of the require
parameter on the file resource /var/log/supervisor/${name}
from Class['supervisor']
to File['/var/log/supervisor']
.
I'll fix this asap.
I think the only way to fix this, is a change of the I'll fix this asap. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Closing due to lack of activity. |
plathrop
closed this
Aug 6, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
doismellburning commentedDec 26, 2012
I believe there's an issue with the dependency ordering such that it's possible to get supervisord into a state where it can't be repaired without manual intervention.
I had a manifest with
environment=>FOO=BAR BAZ
causing supervisord config to be generated withenvironment=FOO=BAR BAZ
, which triggered a quoting bug in the version of supervisord - https://lists.supervisord.org/pipermail/supervisor-users/2010-March/000539.html so supervisord failed to start withStarting supervisor: Error: Unexpected end of key/value pairs
Updating my manifest to fix this, and reloading vagrant to reapply puppet:
I believe this is because, looking at
manifests/service.pp
, the.ini
resource requires the log file:and the log file requires the class:
and I believe the class requires the base supervisord instance to be running, which of course it now won't do due to a broken
.ini
file.I can trivially fix this by manually
rm
ing the broken.ini
file, but this doesn't seem ideal - not sure of the best solution though.