Right now, it seems that running a later chef run starts another of forever's
monitor processes, and somehow confuses the init script as to which PID its
tracking. The current way to fix this is to kill the more recent monitor
processes, and then the single node server process. The remaining (original)
monitor process will then see that the server process has died, and will bring
it back and be properly aware of it.
A likely solution will involve adding a not_if resource attr to the
forever_service LWRP block.
Right now, it seems that running a later chef run starts another of forever's
monitor processes, and somehow confuses the init script as to which PID its
tracking. The current way to fix this is to kill the more recent monitor
processes, and then the single node server process. The remaining (original)
monitor process will then see that the server process has died, and will bring
it back and be properly aware of it.
A likely solution will involve adding a
not_ifresource attr to theforever_service LWRP block.